Microsoft Graph throttling guidance

Throttling limits the number of concurrent calls to a service to prevent overuse of resources. Microsoft Graph is designed to handle a high volume of requests. If an overwhelming number of requests occurs, throttling helps maintain optimal performance and reliability of the Microsoft Graph service.

Throttling limits vary based on the scenario. For example, if you are performing a large volume of writes, the possibility for throttling is higher than if you are only performing reads.

What happens when throttling occurs?

When a throttling threshold is exceeded, Microsoft Graph limits any further requests from that client for a period of time. When throttling occurs, Microsoft Graph returns HTTP status code 429 (Too many requests), and the requests fail. A suggested wait time is returned in the response header of the failed request. Throttling behavior can depend on the type and number of requests. For example, if you have a high volume of requests, all requests types are throttled. Threshold limits vary based on the request type. Therefore, you could encounter a scenario where writes are throttled but reads are still permitted.

Common throttling scenarios

The most common causes of throttling of clients include:

  • A large number of requests across all applications in a tenant.
  • A large number of requests from a particular application across all tenants.

Best practices to handle throttling

The following are best practices for handling throttling:

  • Reduce the number of operations per request.
  • Reduce the frequency of calls.
  • Avoid immediate retries, because all requests accrue against your usage limits.

When you implement error handling, use the HTTP error code 429 to detect throttling. The failed response includes the Retry-After response header. Backing off requests using the Retry-After delay is the fastest way to recover from throttling because Microsoft Graph continues to log resource usage while a client is being throttled.

  1. Wait the number of seconds specified in the Retry-After header.
  2. Retry the request.
  3. If the request fails again with a 429 error code, you are still being throttled. Continue to use the recommended Retry-After delay and retry the request until it succeeds.

The following resources currently provide a Retry-After header:

For a broader discussion of throttling on the Microsoft Cloud, see Throttling Pattern.


If no Retry-After header is provided by the response, we recommend implementing an exponential backoff retry policy. You can also implement more advanced patterns when building large-scale applications.

Microsoft Graph SDKs already implement handlers that rely on the Retry-After header or default to an exponential backoff retry policy.

Service-specific limits

Microsoft Graph allows you to access data in multiple services, such as Outlook or Azure Active Directory. These services impose their own throttling limits that affect applications that use Microsoft Graph to access them.


The specific limits described here are subject to change.

Outlook service limits

Outlook service limits are evaluated for each app ID and mailbox combination. In other words, the limits described apply to a specific app accessing a specific mailbox (user or group). If an application exceeds the limit in one mailbox, it does not affect the ability to access another mailbox.

Limit Applies to
10,000 API requests in a 10 minute period v1.0 and beta endpoints
4 concurrent requests Beta endpoint
15 megabit upload (PATCH, POST, PUT) in a 30 second period Beta endpoint

Outlook service resources

The following resources are provided by the Outlook service.

Calendar API resources
Mail API resources
Personal contacts API resources
Social and workplace intelligence resources
To-do tasks API (preview) resources