Hitting rate limits: which endpoint, headers, and log events to read

Diagnose: rate limits

Symptom

Intermittent 429 Too Many Requests from Auth0 endpoints, sometimes cascading into user-visible failures.

Likely causes

1. /oauth/token hammered by M2M code minting per request.
2. /dbconnections/signup or passwordless endpoints hit by a retry loop or a bot.
3. Management API paginated listing without backoff.
4. Load test or bulk import against the wrong tenant.

Confirm

• Response headers on the 429: Retry-After and Auth0's rate-limit headers name the limit and reset.
• Monitoring > Logs: filter for rate-limit event types. The events name the endpoint and the client. One client dominating = fix the client, not the tenant.
• Correlate timestamps with deploys or cron jobs; a new 429 that starts at 02:00 is a batch job.

Fix

• Token caching with single-flight for /oauth/token.
• Exponential backoff with jitter on 429; honor Retry-After.
• Self-throttle UI resends (passwordless, reset) with countdowns.
• Management API: page slowly, cache, and use the include_totals=false where supported.

Verify

Re-run the offending workload and watch the rate-limit events go quiet. Add client-side metrics on token-request counts so the next regression pages before users notice.

Auth0's rate limit policy documents the per-endpoint limits and headers. Rate-limit event types are in the log event codes. Verified against live docs 2026-09-26.