Drive Jira Automation
Quartz mirrors SLA values into real Jira fields, so native Jira Automation rules can notify, escalate, transition and comment on SLA state with no outbound webhook and no external server.
How it works
Quartz does not push events out to Jira Automation. Instead it keeps SLA values inside Jira fields you can read with a JQL clause or an automation condition. There are two sources of those values, both covered in detail on the SLA Fields page:
| Source | What it gives you |
|---|---|
| Four read-only computed fields (shipped out of the box) | Quartz SLA Status, Quartz SLA Target, Quartz SLA Remaining (min), Quartz SLA Breached count — resolved live per issue, searchable in JQL. |
| Mapped fields, refreshed by the write-back sweep | An SLA value (deadline, time remaining, time elapsed, status text, or breached count) written into a real Jira field you choose, refreshed on a schedule. |
Because the data already lives in Jira, an Automation rule simply reads it. There is no webhook to register, no external endpoint, and nothing leaves Atlassian's cloud.
SLA status is recomputed on demand — Quartz never stores a separate timer database. The fields you automate against are the current computed values, kept fresh by the sweep.
Triggering rules when SLA values change
The scheduled write-back sweep updates the mapped fields on a cadence you choose (every 1, 3, 6, 12 or 24 hours), and only writes a field when its value actually changes, to avoid churn. Two patterns let Automation react:
React to a field value changing
Use Jira's Field value changed trigger on a mapped field such as your SLA status field. When the sweep writes a new value (for example status text moving to Breached), the rule fires.
Run a scheduled rule against a JQL clause
Use Jira's Scheduled trigger with a JQL query over the computed or mapped fields. This is reliable for forward-looking checks like "what is about to breach", which a value-changed trigger cannot express on its own.
Pair the sweep cadence with your rule. A scheduled rule that runs hourly is best matched with an hourly write-back sweep so the fields it reads are current. You can also press Run now on the SLA Fields page to refresh immediately.
Example rules
The three examples below assume you have mapped or are using the relevant Quartz fields. Field names shown are the four shipped computed fields; substitute your own mapped field names where you have created them.
Notify when an issue is at risk
Catch issues before they breach by checking how much budget is left. A scheduled rule running every hour:
Trigger: Scheduled — JQL, run every hour
JQL: project = OPS
AND resolution IS EMPTY
AND "Quartz SLA Remaining (min)" > 0
AND "Quartz SLA Remaining (min)" <= 120
Action: Send Slack / email — "Less than 2h of SLA budget left""Time remaining" is negative when an issue is overdue, so the lower bound of > 0 keeps already-breached issues out of this at-risk notification.
Escalate on breach
When the breached count rises above zero, raise priority and assign to a lead:
Trigger: Field value changed — "Quartz SLA Status"
Condition: "Quartz SLA Status" contains Breached
Actions: Edit issue — set Priority = Highest
Assign issue — to the team lead
Add comment — "SLA breached; escalated automatically"Transition or comment on a missed deadline
Drive a workflow transition from the SLA target date — useful when you mirror the deadline onto a Jira date field:
Trigger: Scheduled — JQL, run every hour
JQL: resolution IS EMPTY
AND "Quartz SLA Target" < now()
Actions: Transition issue — to "Needs review"
Add comment — "Past SLA target date"Quartz SLA Target is the soonest upcoming deadline and Quartz SLA Breached count aggregates across the issue's applicable goals, so a rule keyed on them reflects the worst case across that issue's SLAs.
Mute and excluded comments
Two engine behaviours keep automated rules honest:
| Behaviour | Effect on Automation |
|---|---|
| Muted goals | The write-back sweep skips muted goals, so a muted SLA is excluded from the mapped field values your rules read. The issue panel still shows the goal flagged Muted so it can be unmuted. |
| Excluded actors | Comments from automation and app accounts (and named users you list in Settings) are not counted as a first response, so a rule that posts an auto-reply will not accidentally stop a "time to first response" clock. |
Sweep limits
The write-back sweep is bounded so a large site stays within Forge limits. Per run it searches up to 60 in-scope open issues per SLA and performs up to 400 field writes. The sweep aggregates per field — worst status, breached count, earliest and latest deadline — and writes only changed values.
If you need richer SLA dashboards or exports rather than rule triggers, the Reports page and Radar read the same computed values directly — no field mapping required.
No webhooks, no external server
Everything described here happens inside Jira. Quartz writes its own SLA fields back into Jira and native Automation reads them; there is no outbound webhook and no Quartz-hosted backend. Issue data never leaves Atlassian's cloud.
Was this page helpful? Yes · No · Contact support