Scripting Limitations

ScriptRunner applies a few limits to your scripts when they run. These limits are generous enough for almost every script, and they exist to protect your Jira site; catching runaway loops, oversized payloads, and scripts that never finish, so that one script can't degrade the experience for everyone else.

If you hit one of these limits, it's almost always a sign that the work should be broken into smaller pieces, moved to a scheduled job, or batched. Each limit below explains what it protects against and what to do if you reach it.

Timeouts

Every script has a maximum running time. ScriptRunner stops scripts that run too long, records the run as failed, and logs a message.

Script execution limit: 20 seconds

A script is stopped after 20 seconds of execution. This applies to every script, however it runs: the script console, a test run, an event listener, a workflow rule, and a scheduled job. A scheduled job can run on a frequent schedule, but each individual run is still bound by the same 20 second limit. If a script exceeds it, you'll see: 

text
Your script took too long (more than 20 seconds) so we had to stop it.

Synchronous loops are stopped sooner

Scripts that do heavy synchronous work without await, for example, a tight loop with no I/O, may be stopped after only a few seconds, because nothing is reported back while they run. You may see Your script may have exited, or crashed. Prefer await for I/O and long-running work so your script stays responsive.

If you hit the timeout: avoid pulling large result sets into memory at once. Page through results instead. For long-running maintenance or bulk operations, use a scheduled job rather than the console, and split very large jobs across several runs.

Note: the platform also applies its own infrastructure timeouts to background work, which sit above the 20 second script limit. Your script code is always bound by the 20-second limit regardless.

Data limits

Scripts have limits on how much data they can log and return.

Logging

Log output is capped at 200 KB per invocation, and the amount you can emit scales with the function's runtime. If you're logging inside a large loop, log a summary instead of one line per item, or log only what you need to diagnose a problem.

In addition, a run keeps up to 500 log records; any beyond that are dropped. Very large individual entries are truncated (shown with a [truncated] marker). Logs are also delivered in batches, so they can take about a second to appear; an empty output panel immediately after a run doesn't mean nothing was logged.

Return values and stored data

  • A script's return value is serialized and passed back across the Forge/Jira boundary. Very large return values may fail there, so return only what the caller needs.

HAPI's paginated helpers (for example, the paginated-iterator module) are the recommended way to work through large result sets without holding everything in memory at once.

Script size

There is no fixed maximum on the length of a script, but very large single scripts can still cause problems, including higher memory use and slower runs. For maintainability and performance:

  • Move large blocks of static data out of the script and fetch or store them instead of embedding them.
  • Split unrelated logic into separate scripts.
  • Use HAPI and the built-in libraries rather than re-implementing helpers inline.

Concurrency

When the same script is triggered many times at once, for example an event listener reacting to a bulk update, ScriptRunner runs the invocations through a queue rather than all at the same instant:

  • Background invocations run with a default concurrency of 10 at a time; the rest queue and run as capacity frees up.
  • Scheduled jobs run one at a time. A job will not start a new run while a previous run of the same job is still in progress.

Scheduled job interval

The shortest schedule you can set is once per minute. Sub-minute intervals are rejected when you save the job. Because the platform polls schedules on a fixed cycle, a job may run up to a few minutes after its nominal time rather than to the exact second.

Retries

Background script invocations are not automatically retried if they fail. Write scripts to be safe to re-run, and handle errors within the script where you need recovery.

Jira API rate limits

Calls to the Jira REST API (via HAPI or fetch) are subject to Atlassian's rate limits. Under heavy load Jira may return HTTP 429 (Too Many Requests). If you make many calls in a loop, request only the fields you need, avoid firing unbounded parallel requests, and check response.status so you can back off and retry when needed.

Performance and latency

Some scripts run in response to something happening in Jira, such as event listeners, workflow actions, workflow validators, and automation integrations. Given the asynchronous nature of events in Jira, there can be a short delay between a change in Jira and your script running. This delay varies but is usually a few seconds, and can sometimes be longer and applies to any event-driven script.

Scripts that you run directly, such as from the Script console or an HTTP endpoint, are not affected by this delay.

A script may also run more slowly the first time it runs after a period of inactivity. Because of this, do not rely on an event-driven script running instantly. For example, a workflow action that assigns a newly created work item to its reporter may take several seconds to take effect.

Run history retention

How long a run's logs and result stay available depends on how it was triggered:

  • Triggered invocations (event listeners, scheduled jobs, workflow rules, and so on) are retained for 30 days.
  • Test runs from the script console's Run button are kept for 7 days in the activity table and 30 days in the logs, long enough to read the result, not as a permanent record.

Runtime environment

Scripts run in an isolated sandbox, which shapes what your code can do:

  • Scripts are written in TypeScript (not Groovy) and run in a sandboxed JavaScript runtime.
  • No local file system. Scripts cannot read or write files on a server.
  • Network calls go through the platform. Outbound HTTP uses the built-in fetch API, which is proxied by the platform; only http and https URLs are allowed, and scripts cannot open arbitrary sockets. fetch is provided for you and cannot be replaced from within a script.
  • Always await your asynchronous work. If a script finishes while Promises are still pending, those operations may not complete, and the run is flagged with an error telling you to add the missing await. See Understanding Async and Await.
  • Field behaviours (UI modifications) are different. They run in the user's browser as the form is used, not in the script sandbox, so the 20 second limit above does not apply to them. They are instead bound by the Jira UI modifications API.
On this page