Anyone who has ever run a script to search for, copy or synchronise files in SharePoint may well have come across this: suddenly, the requests freeze and you get error messages instead of results. You might be copying teaching materials or simply working hyper-efficiently in SharePoint using three browsers. And suddenly, you’re left with a blank page.
Microsoft refers to this as ‘throttling’, and it is not a bug, but a deliberate security measure implemented by the service.
What exactly is throttling?
SharePoint Online limits the number of API calls and operations you are allowed to perform within a given time frame. This ensures the service remains fast and reliable for everyone, even if an individual application suddenly sends far too many requests.
If you exceed that limit, SharePoint Online responds in two ways. If you’re working directly in the browser, you’ll be redirected to a warning page and your action will fail. If you’re working via Microsoft Graph, CSOM or REST, you’ll receive an error code 429 (“Too many requests”) or 503 (“Server Too Busy”). For both error codes, SharePoint includes a Retry-After header, which specifies how long you must wait before you can try again. Important to note: rejected requests also count towards your quota. If you ignore this waiting period, you run the risk of being restricted even more severely.
If an application consistently exceeds the limits, Microsoft may block it entirely. The application will then only see error code 503, and the tenant will be notified of this via the Office 365 Message Centre.
Who is most at risk?
For an ordinary user working interactively in SharePoint, throttling is rare. In most cases, it involves custom code: custom web parts, complex list views, synchronisation tools or scripts that process large amounts of data. Even running multiple synchronisation processes simultaneously on different devices can be enough to hit a limit.
Microsoft applies limits at various levels: per user, per tenant and per application. For example, a user is allowed to make a maximum of 3,000 requests every five minutes, whilst applications within a tenant are allocated a quota of resource units that depends on the number of licences. Peak times at the office or school also increase the likelihood of delays, whilst there is generally more capacity at night and at weekends.
How can you avoid throttling?
Microsoft provides some specific recommendations for anyone who builds or manages applications that interact with SharePoint:
- Limit the number of concurrent requests and avoid sudden spikes in traffic.
- Where possible, opt for Microsoft Graph rather than CSOM or REST. Graph is the latest API and generally uses fewer resources for the same operation.
- Bear in mind the Retry-After header and the newer RateLimit headers, which show you early on how close you are to your limit.
- Make sure your traffic is identifiable: register an AppID and AppTitle for your application and include a valid User-Agent string. Unidentifiable traffic is given lower priority than traffic that identifies itself correctly.
- When scanning large numbers of files, it is best to use delta requests with a token. Not only is this more efficient, but it also uses fewer resource units per call.
And what if things do go wrong?
If your school or organisation is blocked, this is due to prolonged, persistent excessive traffic. Microsoft will always notify you of this via the Message Centre, explaining the cause and who you should contact to have the block lifted.
For schools that run their own tools or scripts against SharePoint or OneDrive – for example, for reporting, backups or automation – it is therefore worth checking whether these comply with Microsoft’s recommendations. This will help you avoid a situation where a useful tool suddenly causes delays for everyone in the organisation.
Further information:
Avoid getting throttled or blocked in SharePoint Online | Microsoft Learn
