SharePoint 429 Error - Throttling

[Justin Spiteri]

We have a custom code application which hits SharePoint with multiple ExecuteQueries. This has been running fine for 6 months. From last week, we began receiving a lot of 429 Errors. 

We made sure that that there is a delay of up to 3 secs between each ExecuteQuery and also decorated the HTTP calls as Microsoft suggest in (https://docs.microsoft.com/en-us/sharepoint/dev/general-development/how-to-avoid-getting-throttled-o...). Also multiple users are being used so that not always the same user is used when hitting SharePoint.

Has anyone encountered this? Does anyone know the actual values of throttling in SharePoint or what triggers it?

[#2]

Please share us details around your issue at https://github.com/SharePoint/sp-dev-docs/issues, so that we can route this properly internally thx. 

[#3]

Hi Enric,

unfortunately we did not get any official replies from Microsoft neither, other then the ones in this forum, however these 429 errors vanished without us doing nothing. We experienced these errors throughout the month of February and while the 429 errors began without us doing any changes, we still did a lot of suggested improvements in our code such as waiting to hit SharePoint for the timeout specified in the 429 error, using multiple users and decorating HTTP.

However after these changes were implemented, the errors were still occurring. Then at the end of February, they just stopped occurring.

Regards,

Justin

[#4]

Hi Vesa,

we already posted https://github.com/SharePoint/sp-dev-docs/issues/1710 and https://github.com/SharePoint/sp-dev-docs/issues/1711 four days ago, and we're collecting data for a third one today. 

In the meantime, support tickets are open by these customers, although we didn't get specific replies yet.

So, as some productive systems are affected (= unusable) and every day counts, this is extremely concerning for us, and I wanted to get some feedback from the users that originally faced this 2 months ago.

I understand that every issue needs to be properly diagnosed and assessed, so I really appreciate all the efforts you're already making. Please let us know if we can help with any action/test/troubleshooting from our side. There is critical business around this issue and we're willing to help as much as possible.

Thank you!

@Justin Spiteri Thanks a lot for your feedback, I'm glad your issues got solved.

[#5]

At the time we got the suggestion to only start our processes (migration) after business hours (18:00-07:00). That helped us limiting the throttling errors. We were also using ShareGate and they updated their software as well to minimise the 429 errors. 

I had a feeing it also depend on the location of your tenant, ours at the time was in the UK.

[#6]

@Enric Carrión One suggestion I could mention is how we have tried to deal with this situation while these errors were occurring. As mentioned in my previous reply, we modified our solution to stop hitting SharePoint for the amount of time that is mentioned in the 429 error (usually 2 minutes).

Of course this effected us very negatively as all systems were very very slow and we were asking our users to not use the system unless they really need to. But at least we managed to limp trough this situation until somehow it got resolved on it's own.

[#7]

We have encountered again error 429 and also error 503 last week. Although we haven't seen any more in the past 4 days, we are curious again on what might have triggered this issue. We have told our users to not use SharePoint for the time being, so that might have helped in stopping these errors, but we cannot say for sure.

From our end, the only new change we did is that we started evaluating a 3rd party software (Metalogix) to take a backup of our Office 365 solution. Our tests were mainly backing up of 2 small mailboxes (multiple times due to different tests) to our Azure blob storage.

Would it be possible that our solution (previously mentioned) together with Metalogix caused this issue again?

All we would like to know is:

1. How are we being throttled?

2. How could we know what is causing the throttling?

3. What are our limits?

Currently we are in a situation where the company is constantly growing and of course we are constantly increasing the adoption of Office 365 to all our users, especially in SharePoint and Teams. Our fear is that if we increase more usage and applications on our Office 365 solution, the more we are going to encounter these throttling issues. So without having any information on the 3 points mentioned above, we cannot plan any future applications on SharePoint.

Does anyone encountered the same issue lately?

[#8]

Hi,

Yes this is probably causing the issue. I have been told during Inspire 2018 in Vegas that the main issue with the tenants is caused by the increase of activities using backup software. Microsoft is therefore using algoritmes to block throttle backup software.

Can you try running after working hour backups?

[#9]

In case you haven't seen it, there's new guidance regarding throttling. 

The latest version of CSOM (16.1.8316.1200) added support for RetryQuery when throttled.

It will not change anything in relation to when you're being throttled. It changes the way it should be handled.

https://github.com/SharePoint/PnP-Sites-Core/issues/1892

[#10]

HELLO @Justin Spiteri. I am not a coder but i use onedrive like online cloud storage. I have been facing this issue since 3 months and i am still unable to get help. PLEASE CAN YOU GUIDE ME TO SOLUTION?? i am unable to access my important files on my online drive!. m4eer9kc9060@onedrive.69ssr.us this is my mail. I WILL BE VERY GRATEFUL FOR YOUR KINDNESS.