503 service unavailable when sending emails through graph API

Question

We got the above error when trying to send mail using the graph api. This happened on 12/29/2024 starting around 9 AM.

 

The response logged was - {"error":{"code":"ResourceUnhealthy","message":"MdbReplicationProtectionUtilizationMonitor is unhealthy."} }. Based on what I see online there this is related to the throttling issue with 503 error and the recommendation is to use the retry after header as we are doing now.

 

After waiting for the time mentioned in the retry after header we still got the same error and a longer retry after header. Why is this error actually happening. Is there a place where we can see why and the when the server is unavailable. If there was an outage where can we find information about the same.

Answer 1

Hello Abhishek Mendon,

Thank you for reaching out to Microsoft Support!

For a server-side problem like yours, I suggest you open a support ticket with Microsoft Support to get help from the API owner.

Hope this helps.

If the answer is helpful, please click Accept Answer and kindly upvote it. If you have any further questions about this answer, please click Comment.

Answer 2

Hi Abhishek Mendon,

Thanks for reaching out to Microsoft!

503 error occurs when the service is temporarily unavailable for maintenance or is overloaded. You may repeat the request after a delay, the length of which may be specified in a Retry-After header.

In-Order to handle Exchange/Outlook Service Specific Throttling errors, first we need to understand which all limits applies. The Outlook service applies limits to each app ID and mailbox combination - that is, a specific app accessing a specific user or group mailbox. Exceeding the limit for one mailbox does not affect the ability of the application to access another mailbox.

Once the application goes over these limits, service will send back HTTP status code 429 and response body will contain the details of the throttling error, such as:

•            Application is over its RequestRate limit

•            Application is over its MailboxConcurrency limit

•            Application is over its IncomingBytes limit

Using Retry-After Logic

When a 429 response is returned, the client should use the Retry-After header to determine when it is safe to retry the request. Application should Wait and retry after the number of seconds specified in the Retry-After header. 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. MailboxConcurrency limit is not time-based limit. So, if you have a retry-after logic that retry after "x" specified seconds, it's going to be total failure, because for MailboxConcurrency retry-after value of "1" signify you need at least 1 concurrent call to complete to get back below the concurrency limit of 4 before making another call to the same mailbox. So, the retry should only happen when the request concurrency goes below 4.

Throttling Guidance

Hope this helps.

If the answer is helpful, please click Accept Answer and kindly upvote. If you have any further questions about this answer, please click Comment.