JavaScript automation for Jira Cloud

Make the workflow do the routine work.

Mercury runs your JavaScript after a Jira transition. Scripts execute in an isolated backend runtime with a small, permission-checked Jira API.

Write your first script See how isolation works

Workflow post-functions support all eight checked Jira helpers.

transition.js

const current = await jira.getIssue(issue.key);
const status = current.fields.status.name;
const summary = current.fields.summary;

await jira.updateIssue(issue.key, {
  fields: {
    summary: `[${status}] ${summary}`
  }
});

console.log("summary updated", issue.key);

Runs on Mercury's Forge backend

QuickJSFresh runtime for each invocation

Default CSPNo browser eval or WebAssembly

Bounded accessNamed Jira helpers only

Forge hostedRuns inside Atlassian Forge

Get started

A workflow script in three steps

Add Mercury to a workflow transition, write your script, and test it with sample issue data.

Open a transition
Edit a company-managed or team-managed workflow. Select the transition that needs automation.
Add a Mercury script
Add the Mercury post-function and write JavaScript with the documented context and helpers.
Validate and simulate
Run a simulation and inspect the proposed Jira updates before saving the rule.

Runtime model

Your code gets a narrow door into Jira.

The editor sends source to a Forge function. A fresh QuickJS runtime compiles and runs it. The script receives JSON data and named Jira helpers, never Forge credentials or Node.js globals.

Forge receives the transition

Mercury checks the app license and parses Jira's event into a stable script context.

QuickJS starts clean

Each run gets its own memory and time limits. Host globals such as process, require, and fetch are absent.

Helpers enforce policy

Every Jira call crosses a checked backend boundary. Scripts cannot make arbitrary network requests.

Mercury records the outcome

Bounded console output and a structured result make failures diagnosable without exposing credentials.

Script reference

Eight focused Jira helpers

Select a helper to inspect its implemented contract and copy an example. Workflow scripts and workbench scripts use the same API.

`issue`

The transitioned issue with id, key, and the fields Jira supplied.

`transition`

The transition ID plus normalized from and to statuses.

`actor`

The initiating account ID when Jira includes one. The value can be null.

`console`

Bounded log, warn, and error methods.

Copy a complete recipe

Examples

Change the input and inspect the recorded update

This local example runner does not execute code or contact Jira. It demonstrates how the documented update payload changes.

Recorded jira.updateIssue call

Automation workbench

Build, run, and monitor scripts

Jira administrators can open eight connected views. The backend checks Jira administrator permission for every action.

Console

Simulate, then confirm a live run

Write a script of 24 KiB or less.
Select Simulate to use the DEMO-1 sample. Simulation records writes and never changes Jira.
Enter one issue key and select Review live run.
Check the exact source and issue key. Select Run live before the one-use confirmation expires after five minutes.

In simulation, search accepts only project = DEMO or key = DEMO-n. Sample transitions are 11 To Do, 31 In Progress, and 41 Done.

Mercury consumes the confirmation and creates the running history record in one atomic operation. Live console runs use the Mercury app identity.

Scripts

Save and pin revisions

Select Save revision to create an immutable revision.
Open Scripts to review or load an older revision.
Choose a saved revision when you create a listener or scheduled job.

An automation stays pinned to that revision. Archiving a script prevents new enables, but it does not disable automations that already use the revision.

History

Inspect the last 30 days

Open History, then select Refresh to load runs completed since the page opened. Inspect the origin, issue, start time, duration, Jira call count, and fixed failure code. Guest console values are not retained.

A run left as running after a crash has an uncertain outcome. Mercury does not retry it automatically. If only final history storage fails, the console still returns the actual script result and live logs with a finalization-failed warning.

Listeners

React to issue events

Choose Issue created or Issue updated.
Enter the required project key.
Choose a saved revision and save the listener disabled.
Enable it after you review the source and project.

Scheduled jobs

Run against one issue

Choose one issue key and a saved revision.
Select Every hour, Every day, or Every week.
Save the job disabled, then enable it when ready.

Intervals use UTC epoch buckets rather than a wall-clock appointment.

Privacy controls

Declare, report, and erase personal data

Mercury tracks the author automatically. Administrators declare account IDs for other people named in retained source, names, and settings.

An empty declaration means the administrator reviewed the authored content and asserts that it contains no other person’s personal data. Erasure can remove shared scripts and dependent automations. Exported copies remain the administrator’s responsibility. Read the Cloud privacy notice.

Safe operations

Know what runs before it writes

Mercury gives Jira administrators a read-only path for real issue data, installation controls, recent health, and portable configuration.

Set limits.Open Usage & health. Review hourly and monthly limits and the emergency pause.
Test safely.Start with sample simulation, then select Dry-run real issue before a live write.
Review automation.Save an immutable revision. Check its event, project, issue, and interval before enabling it.
Keep a backup.Export configuration after a reviewed change. Restored automations stay disabled.

Dry-run real issue

Read Jira, intercept writes

Choose one issue and run with app-authorized real Jira reads. Mercury returns proposed writes without sending them. Retained history excludes proposed writes and Jira response values. A dry run cannot prove Jira would accept those writes.

Usage & health

Bound each installation

Mercury admits at most 100 runs per UTC hour and 10,000 per UTC month. Sample simulations count. Administrators can lower those limits or pause new runs. In-flight runs continue.

Automation health

See the latest outcome

Health shows the latest success or failure for workflows and automations, including failures that happen before a normal history record starts.

Backup

Move reviewed definitions

Export current source and older snapshots pinned by automations, with up to 25 definitions. The bundle emits definitions disabled. Import creates standalone scripts and automations with new local IDs.

Automation delivery

Bounded work with visible tradeoffs

Mercury uses loop protection and records an auditable result without automatically replaying failed work.

25 definitions

An installation can store up to 25 listener and scheduled-job definitions. Up to five can be enabled at once.

30-day identity

Mercury deduplicates each automation and event or schedule bucket for 30 days. Editing or toggling it does not clear that claim.

Loop protection

Listeners skip events marked selfGenerated or carrying a Mercury trace value.

No automatic retry

Jira may accept some writes before a failure. Mercury records the failure and does not promise exactly-once effects.

How listener identity works

Created events use the Jira issue ID. Updated events require both the issue ID and a changelog ID. Mercury skips an updated event when that stable identity is missing. It also drops an event whose timestamp is more than 24 hours from receipt.

How schedule buckets work

One coarse hourly Forge trigger checks enabled jobs. A job uses a 1, 24, or 168-hour UTC epoch bucket. The first trigger after enablement can run the job. Missed intervals coalesce into the current bucket.

The claim uses the automation ID and bucket identity. Editing, disabling, or re-enabling a job does not run the same claimed bucket again.

What delivery does not guarantee

Mercury prevents known duplicate dispatches for 30 days. It does not provide exactly-once Jira writes. It does not retry failed runs automatically. Scripts can leave partial Jira writes when a later helper call fails.

Cloud pricing

Pay for the Jira users on your site

Marketplace billing uses the number of billable Jira users, not the number of Mercury administrators. Up to 10 users costs $10 per month. From 11 users, the progressive schedule counts every user.

Progressive monthly rates

Users	Rate per user
Up to 10	$10 flat
1–100	$1.00
101–250	$0.90
251–1,000	$0.75
1,001–2,500	$0.60
2,501–5,000	$0.50
5,001–7,500	$0.45
7,501–10,000	$0.40
10,001–25,000	$0.30
25,001–50,000	$0.25
50,001–100,000	$0.20

Single-instance and multi-instance customers use the same rates. Annual Marketplace pricing is 10 times the monthly price at the annual tier ceiling. Multi-instance customers use annual billing.

Each installation can admit up to 100 runs per UTC hour and 10,000 runs per UTC month. These execution limits do not vary by seat count.

Open Atlassian Marketplace for the exact annual quote and applicable tax →

Cloud features

What you can do with Mercury

Server to Cloud

Port the intent, not the Groovy source

Mercury Server scripts run inside Jira's JVM. Mercury Cloud scripts use JavaScript and checked Jira helpers inside Forge.

Concern	Mercury Server	Mercury Cloud
Language	Groovy	JavaScript
Runtime	Inside Jira's JVM	Isolated QuickJS on Forge
Jira access	Jira Java classes	Named asynchronous helpers
Files and network	Depends on server access	No guest filesystem or arbitrary network access
Failure behavior	Depends on Jira Server transaction context	Completed Jira updates cannot be rolled back

Server

issue.setFixVersions([
  versionManager.getVersion(
    issue.projectObject.id,
    'NEXTBUILD'
  )
])

Cloud pattern

const versionId = "10014";
await jira.updateIssue(issue.key, {
  fields: {
    fixVersions: [{ id: versionId }]
  }
});

Open the complete Server documentation and legal terms →