Answer: ScriptRunner scripts, listeners, scheduled jobs, and workflow functions are configuration. They are not part of standard Jira issue data, and they are not included in native Jira Cloud exports. After a data loss event, ScriptRunner configurations must be restored from a backup that explicitly captures app-level configuration, or rebuilt manually from version-controlled source. Without one of those, your automation logic is gone, and so is the operational behavior that depended on it.
ScriptRunner is the engine behind a large fraction of enterprise Jira automation. It powers custom workflow validators, conditional transitions, scheduled jobs that re-balance backlogs overnight, listeners that fire when issues change, and behaviors that control field visibility and required fields. When a data loss event happens, the data is the obvious concern. But the automations are often what made the data move, and they restore very differently from the data itself.
Where ScriptRunner stores its work
ScriptRunner stores its configurations as app-level data inside Jira: scripts in script repositories, listener configurations, scheduled job definitions, custom workflow functions, behaviors, and fragments. These are persistent objects, but they are not Jira issues, comments, or attachments. They sit in the configuration layer alongside workflow schemes and permission schemes, which is the part of Jira most backup tools handle weakly or not at all.
What breaks when ScriptRunner is not part of your backup
Three patterns of breakage are typical:
- Workflows refuse to transition. Custom validators and conditions that referenced ScriptRunner functions return errors. Tickets get stuck. Engineering escalates. Admins spend hours diagnosing whether it’s a workflow scheme problem, a permission problem, or that the underlying script no longer exists.
- Scheduled jobs stop running. Nightly rebalancing, weekly cleanup, monthly archival: these don’t fail loudly. They simply stop. The first signal is usually a downstream metric drifting in the wrong direction days or weeks later.
- Field behaviors revert. Fields that were required in some contexts become optional. Fields that were hidden become visible. The ticket schema looks correct, but the rules that governed its use are gone.
The recovery options, ranked
There are three credible paths to recovering ScriptRunner state, in descending order of preference:
- Restore from a configuration-aware backup. If your backup tool captures Marketplace app configuration as a first-class object, not as an afterthought, you can restore ScriptRunner state to a known-good point in time alongside the rest of the Jira instance.
- Rebuild from version-controlled source. Mature teams keep their ScriptRunner scripts in a Git repository, with deployment to Jira treated as code deployment. This is excellent practice and worth doing regardless of your backup posture, but it covers scripts only, not all listener and job configuration, and rebuilding scheduled jobs and bindings manually still takes time.
- Manual reconstruction. The worst option. Admins reconstruct configurations from memory, documentation, and Jira’s own audit log if it’s enabled. Typically takes days to weeks for non-trivial deployments and rarely produces a faithful restore.
The pre-incident checklist
Before an incident occurs, the questions to answer for every ScriptRunner deployment are:
- Is every script in version control with a deployment record tying script versions to dates?
- Does your backup tool explicitly capture ScriptRunner configuration, or only Jira issues?
- Do you have a documented inventory of all scheduled jobs, listeners, behaviors, and fragments at the granularity an admin would need to rebuild from scratch?
- When was the last time you tested restoring ScriptRunner configuration end-to-end, not just the scripts themselves?
If the answer to any of these is uncertain, that uncertainty is your real recovery time.
A specific resilience pattern that works
The pattern enterprises with mature Atlassian operations converge on combines three things: scripts maintained in Git with CI/CD into Jira, app-level configuration captured by a third-party backup that understands Marketplace apps, and a quarterly drill that restores ScriptRunner state into a sandbox to validate that the restore actually produces working automation. None of these is complicated. The discipline is in doing them all.
The broader point
ScriptRunner is one of dozens of Marketplace apps that store configuration alongside Jira data. The same recovery logic applies to automation engines, integration apps, structure and portfolio tools, and reporting apps. Each of them encodes business logic that the Jira instance depends on. Treating any of them as though “the vendor handles it” is the same mistake as assuming Atlassian handles your data. The model is shared responsibility, and the responsibility for app-level configuration is yours.
Sources
- Atlassian — Shared responsibility and data management — https://www.atlassian.com/trust/security/data-management
- Atlassian — Configuring custom field contexts (Data Center) — https://confluence.atlassian.com/adminjiraserver/configuring-custom-field-contexts-1047552717.html
Rewind">
