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

TL;DR: Symptom: intermittent 429s. Cause: one hot endpoint or one misbehaving client. 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. Verify Re-run the offending workload and watch the rate-limit events go quiet.

The fix

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.
5. Response headers on the 429: Retry-After and Auth0's rate-limit headers name the limit and reset.
6. 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.
7. Correlate timestamps with deploys or cron jobs; a new 429 that starts at 02:00 is a batch job.
8. Token caching with single-flight for /oauth/token.
9. Exponential backoff with jitter on 429; honor Retry-After.
10. Self-throttle UI resends (passwordless, reset) with countdowns.
11. Management API: page slowly, cache, and use the include_totals=false where supported.

When to use this

• This covers exactly what the title says: Hitting rate limits.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Hitting; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Hitting behavior.

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.