Limits and Quotas
To ensure ScriptRunner Connect's service reliability, the app applies various limits and quotas to guard against accidents or malicious behavior.
General Limits
| Limit | Free Tier | Silver Tier | Gold Tier | Platinum Tier |
| Record Storage capacity | 100 MB | 1 GB | 5 GB | 10 GB |
| Maximum async (fire and forget) script invocation duration* | 15 minutes | |||
| Maximum sync script invocation duration (only applies for Sync HTTP Events) | 25 seconds | |||
| Maximum event payload size | 6MB | |||
| Maximum chained invocations (programmatically triggered) | 200 | |||
| Maximum console logs per invocation | 1000 | |||
| Workspaces per account | 1000 | |||
| Connectors per account | 1000 | |||
| API connections per workspace | 1000 | |||
| Event listeners per workspace | 1000 | |||
| Event listener test payloads per workspace | 1000 | |||
| Scheduled triggers per workspace | 1000 | |||
| Environments per workspace | 1000 | |||
| Deployments per workspace | 10000 | |||
* To run workloads longer than 15 minutes, you can use a Trigger Script API when you are about to reach the timeout limit. This allows you to trigger the same script to continue where the previous invocation left off.
Rate limits
Rate limits, comprised of burst limit and refill rate, are calculated as follows:
- Burst limit - The number of service calls you can make before getting rate-limited.
- Refill rate - The number of tokens added back to your burst limit quota every second.
For example, if the burst limit is 100 and the refill rate is 25, that means you can call the service 100 times instantaneously, then it would take four seconds to refill your burst limit quota, as the refill rate adds 25 tokens back each second.
Free Tier | Silver Tier | Gold Tier | Platinum Tier | |||||
|---|---|---|---|---|---|---|---|---|
Burst limit | Refill rate | Burst limit | Refill rate | Busts limit | Refill rate | Burst limit | Refill rate | |
| Script Invocations** | 5 | 1 | 50 | 25 | 100 | 50 | 200 | 100 |
| External (Fetch) API calls *** | 10 | 5 | 100 | 25 | 200 | 50 | 400 | 100 |
| Record Storage API calls | 5 | 1 | 20 | 10 | 50 | 25 | 100 | 50 |
| Trigger Script API calls | 1 | 1 | 10 | 2 | 25 | 5 | 50 | 10 |
** Script invocations that go over the limit and are triggered either by asynchronous incoming events, like event listeners or scheduled triggers, are pushed into the retry queue and return a 429 status code indicating that the event will be processed with a slight delay. The retry queue attempts to retrigger queued invocations later when the burst-limit quota allows it. If the retry queue fails to trigger the queued invocation after 100 attempts, the invocation drops from the queue.
Synchronous incoming events (currently only Sync HTTP Endpoints) that need to return the script response quickly (29 seconds) attempt to retrigger the script for up to 20 seconds; after this point, a 429 response is returned. Synchronous events that are rate-limited but successfully retried have less time to run the script as the maximum time to return a response is shortened by retry attempts. You can check the time you have to return a response from the context object that is passed into your function as the second parameter.
Manually triggered scripts won't be queued if the rate limit is exceeded; they will be blocked.
*** External API calls rated limited by ScriptRunner Connect side will return a 429 response, which can also be the same response from the external service if you have breached the rate-limit quota. By default, Managed APIs come with a setting that retries rate-limited (429) requests up to a certain extent. If you are using low-level Fetch API, you must implement retry logic.