The Microsoft 365 app version uses shared resources provided by the app, primarily the Azure app services that execute the various background processes of the app. For instance, each time an action is executed, one of the app services executes the process. That means usage of CPU and RAM resources, as well as taking up one of the available network connections.
The resources are shared between different tenants and it's our responsibility that one tenant is not using up more than their fair share of the resources, which might impact other tenants. That is why we developed a sophisticated throttling mechanism that monitors usage by each tenant and automatically prevents abuse by halting execution or preventing further processes from being started.
There are two main parameters that we measure for each component that performs background execution: duration and frequency.
- Duration - the length of execution time for a single process. For instance, how long it takes for an action to execute. If the duration exceeds the predefined threshold, it is halted with an error. The usual limit for a medium-large customer is 500 second during peak time and 1500 seconds during off-peak hours.
- Frequency - how often is the process being called by the same list. If the predefined threshold is exceeded, no more processes will be allowed to start from the list within the same day. We count the number of times during the day that the list requested a large number of executions per minute. For example, if a list requested 100 actions per minute, that would be considered as first occurrence. Once 20 such occurrences are registered within the same 24 hour period, all further actions on the list will not be executed until the end of the 24 hour period.
- Errors - number of critical (fatal) errors encountered by lists on the current site. Critical errors are ones that prevented execution of the components after 5 attempts. In most cases, critical errors would indicate a state of being throttled by SharePoint itself due to high volume of operations, exceeding throttling limits. You should examine your automation rules, add-ons, custom code and Flows to ensure you are not performing excessive calls into SharePoint API. Actual limits are not disclosed by Microsoft, but from past experience executing thousands of calls per minute will result in being throttled. Read more here.
The actual thresholds depend on many factors, such as time of day, the executing component and the license level of the customer.
The only components monitored are those, which execute any type of background logic on our Azure app services.
- Actions - both frequency and duration are monitored
- Alerts - both frequency and duration are monitored
- Import - duration is monitored
- Item ID - frequency is monitored
- Associated Items Summary - frequency is monitored
Note that your chances of actually being throttled are very low and it will usually indicate some error in your settings. For instance, running an action that attempts to update hundreds of items in one go will most likely result in throttling, but a regular action that updates one or several items will run fine. Another example: when you run a large number of update in your list (for instance, some 3rd party sync or bulk update), it will result in a large number of alert requests being generated, which can also result in throttling. If you are planning to run bulk updates, consider turning on the Bulk Update Mode to stop any actions/alerts from being executed during that time period.
You can monitor your execution and identify problems before they happen using Monitoring page within Ultimate Forms. Here you can see the potentially problematic sites and lists within your site collection and prevent any possible throttling errors before they occur.
