Write SLA data to Jira fields
Quartz can mirror an SLA's deadline, status, remaining time and breach count into real Jira fields on each issue, so the values live in Jira itself — searchable in JQL and usable by Jira Automation, with no outbound webhooks and no external server.
How the write-back works
SLA status in Quartz is computed on demand — nothing is stored. The write-back is how you push those computed values into durable Jira fields so the rest of Jira can use them. A scheduled trigger sweeps your in-scope open issues on a fixed cadence and writes the mapped values into the fields you choose.
Everything stays inside Atlassian: Quartz reads issue data to compute, then writes only its own SLA values back into Jira fields. There is no outbound webhook and no Quartz-hosted server — the "bridge" to Jira Automation is simply an in-Jira field that gets kept fresh.
The write-back only changes a field when its value actually changes. A "time remaining" field refreshes each run because it counts down; a deadline rarely changes, so it is left alone. This avoids needless edits and notification churn.
Which SLA values you can write
For a given SLA, you map one SLA value onto one Jira field. The values you can write are:
| SLA value | Field type it suits | What it holds |
|---|---|---|
| Deadline | Date / date-time | The SLA's target date for the issue |
| Time remaining | Number (minutes) | Minutes left; negative when overdue |
| Time elapsed | Number (minutes) | Business-hours minutes counted so far |
| Status | Text | The status as text (On track, Breached, …) |
| Breached count | Number | How many goals on the issue have breached |
When several SLAs apply to one issue, the sweep aggregates per field: it writes the worst status, the total breached count, and the earliest or latest deadline as appropriate.
Ready-made computed fields
If all you need is to search and automate on SLA data, you may not need to map anything. Quartz ships four read-only computed Jira custom fields out of the box. They resolve live per issue and are searchable in JQL and usable in Automation:
| Field | Type | Notes |
|---|---|---|
| Quartz SLA Status | String | The SLA status as text |
| Quartz SLA Target | Date-time | The soonest upcoming deadline |
| Quartz SLA Remaining (min) | Number | Negative when overdue |
| Quartz SLA Breached count | Number | Count of breached goals |
Because these resolve on the fly, they always reflect the current computed state without waiting for a sweep. Use the mapped write-back (below) when you need the value written into a specific existing field, or into a field of a particular type that your automations or boards already read.
Map an SLA value to a field
Open the SLA Fields section to set up a mapping. You can write to a field that already exists, or have Quartz create a new Jira custom field for you.
Pick the SLA and the value
Choose which SLA definition to write from, and which of its values (deadline, time remaining, time elapsed, status, or breached count) you want to push.
Choose the target field
Select an existing Jira field of a suitable type, or ask Quartz to create a new custom field for the value.
Set the cadence and save
Pick how often the sweep runs, save the mapping, and optionally use Run now to populate the field straight away rather than waiting for the next scheduled run.
Creating a brand-new Jira custom field is an instance-wide, Jira-admin operation. If you have the manageFields capability but are not a Jira admin, Quartz will ask you to map an existing field instead. See Permissions.
Refresh cadence and the sweep
A scheduled trigger runs the write-back hourly by default; you choose the cadence per your needs — every 1, 3, 6, 12 or 24 hours. You can also trigger an immediate pass with Run now.
Each sweep has guard rails so it stays light and predictable:
| Limit | Value |
|---|---|
| Issues searched per SLA | 60 |
| Writes per sweep | 400 |
The sweep only touches in-scope open issues, and goals that have been muted on an issue are skipped — a muted goal is excluded from the write-back just as it is from breach counts, the Radar and Reports. The issue panel still shows the muted goal, flagged so it can be unmuted later.
Comment-based clocks honour your excluded actors here too. An automated auto-reply is not counted as a first response, so a field driven by a "time to first response" SLA reflects the first human reply, not the bot's.
Use the fields in JQL and Automation
Once a value is in a real Jira field, the rest of Jira can read it. Search for it directly in JQL:
"Quartz SLA Status" = Breached AND resolution IS EMPTY ORDER BY "Quartz SLA Target" ASCThe same fields can drive Jira Automation rules natively — for example, escalate an issue when its SLA status becomes Breached, or notify a lead when remaining minutes drop below a threshold. Because the data lives in a Jira field, no webhook or external service is involved.
Drafting and explaining mappings
The write-back and the four computed fields are available on every edition. The AI features that help you author SLAs — such as drafting an SLA from a plain-language policy Advanced — are part of the Advanced edition, and like all Quartz AI they run on Atlassian-hosted Claude inside Atlassian, so prompts never leave the platform.
Was this page helpful? Yes · No · Contact support