TooManyRequests
Microsoft Graph throttled the request
Answer: The caller exceeded a Microsoft Graph service limit and should delay before retrying.
Resolution playbook
Fix it, then prove it
Use the error record as the starting point; use tenant evidence to confirm the actual cause.
Likely causes
- A failed request still consumes resources. Aggressive retry loops make throttling worse.
- The token is missing, expired, for the wrong audience, or contains the wrong delegated/application permission type.
- Consent, Microsoft Entra role, licensing, resource ownership, or endpoint-specific authorization is still insufficient.
Recommended fix
- Honor the Retry-After response header.
- Use exponential backoff when Retry-After is unavailable.
- Reduce polling, batch compatible work, and avoid immediate retries.
Verify
- Acquire a new access token after permissions or consent change.
- Confirm delegated permissions appear in scp or application permissions appear in roles, and that aud targets Microsoft Graph.
- Repeat the exact HTTP method and endpoint and confirm the response no longer returns the same request ID/status.
Escalate when
- The failure persists after the documented prerequisites and a new authentication/session attempt.
- Multiple users, apps, devices, or networks show the same error, suggesting tenant policy or service scope.
- You can provide the exact UTC time, tenant, application/resource, correlation or request ID, and sanitized logs.
Inspect the active Graph PowerShell context
Get-MgContext | Select-Object ClientId,TenantId,Account,AuthType,ScopesRead-only. Confirms tenant, auth type, and delegated scopes. For app-only tokens, also inspect the token roles claim.
Admin context
A failed request still consumes resources. Aggressive retry loops make throttling worse.
Evidence to preserve
- UTC timestamp and correlation/request ID
- Tenant, application, resource, and authentication flow
- Sanitized service log details and exact operation
Advertisement
