Troubleshooting
Quick fixes for the things that most often look wrong — a missing SLA tile, off-by-hours timers, an empty Radar, stale Jira fields, or locked AI — each with the setting to check.
Quartz computes every SLA on demand — nothing is stored or backfilled. So most "wrong" results trace back to configuration (scope, clock, calendar, permissions), not stale data. Fix the setting and the number recomputes on the next view.
An SLA isn't showing on an issue
If a tile you expect is missing from the issue panel, the SLA almost certainly does not apply to that issue — or its clock has not started. The panel tells you which.
Open the "No SLA applies — why?" diagnostic
When no goal applies, the panel lists every configured SLA that was skipped and the specific reason — Disabled, or Out of scope with the dimension that failed (project, issue type, or priority). When some SLAs do apply, look for the collapsed "N other SLAs not applied — why?" note. Start here before changing anything.
Check the SLA's scope
A definition's "applies to" uses project keys, issue types, and priorities. All specified dimensions must match (AND across dimensions, OR within one); an empty dimension means no constraint. If the diagnostic says a dimension failed, edit that SLA under SLAs and widen or correct it. See Create an SLA.
Check the clock and JQL tiers
The tile can apply but show Measuring or no target if the clock has not started or no tier matched. Confirm the start condition(s) have actually been met on the issue (the "Why this status?" explainer shows what the clock is waiting for). If a target duration is set by a JQL tier, confirm the issue matches a tier — the first matching tier wins, so order and clauses matter.
Confirm the SLA is enabled
A disabled definition never applies. Re-enable it under SLAs.
If the tile shows but its goal is wrong on one issue only, you may have used Extend or Mute. A muted goal still appears flagged "Muted"; an extension shows as "+Xh extended". Both are clearable from the panel.
The time looks wrong
Quartz timers count business time only — nights, weekends, holidays, closed exceptions, and any active pause are skipped. A figure that "looks too low" is usually working as designed.
Check the assigned calendar
Elapsed time and due dates are projected through the SLA's working-hours calendar. If the SLA uses cal_default (or a custom calendar) but you expected round-the-clock counting, assign the seeded 24/7 calendar instead — or vice versa. Review the weekly schedule, business-day hours, holidays, and closed exceptions under Calendars.
Check holidays and closed exceptions
Company-wide holidays (fixed and recurring) and a calendar's closed exceptions are skipped by every timer. A long gap in elapsed time across a date range is usually a holiday or closed day.
Check for paused time
Time while a pause condition holds (e.g. "waiting on customer") is excluded and resumes automatically. The panel shows paused intervals as "Paused — not counted", and the Cycle breakdown modal lists worked time per cycle and every pause interval, recomputed on demand. Use it to see exactly where the time went.
A date-field target breaches when "now" passes the literal wall-clock value in the issue's date field — it is not projected through the calendar. If a date-field SLA's due instant looks off, check the source field's value and time zone on the issue, not the calendar.
On the Radar and Reports, issues that could not be fully evaluated in an aggregate scan are counted "approximately" and the UI warns that pause time may be over-counted. The single-issue panel always uses the exact result, so trust the panel for the exact figure.
A user can't see the Radar or Reports
Two separate things govern what a user sees: whether the view is permitted to them, and which issues Jira lets them browse.
Check the view permission
viewRadar and viewReports are open by default — everyone may view unless an admin has restricted that view to specific groups. If a user hits a friendly no-access state, an admin has restricted that view away from their groups. Adjust it in the group × capability matrix under Permissions (admin-only to edit).
Check what issues the user can browse
An empty or sparse Radar/Reports for one user is usually correct. Every scan runs as the calling user via asUser JQL search, so Jira filters results to the issues that person can browse. If they lack the Browse Projects permission on a project, those issues simply will not appear — fix it in Jira's project permissions, not in Quartz.
Even if an admin restricts every console view away from a user, their per-issue SLA panel still works on issues they can open. The panel is not gated by the Radar/Reports view permissions.
Fields aren't updating in Jira
SLA values are written into real Jira fields by a scheduled sweep — there are no outbound webhooks. If a mapped field looks stale, the sweep either has not run yet or skipped the value.
| Symptom | What to check |
|---|---|
| Field never populates | Confirm the mapping exists and is enabled under SLA Fields, and that the field is on the issue's screen. |
| Field is stale, not blank | Check the sweep cadence (every 1/3/6/12/24h). The sweep only writes when a value changes — a deadline rarely changes, while time remaining refreshes each run. Use Run now to force an immediate sweep. |
| Some issues never update | The sweep caps at 60 issues searched per SLA and 400 writes per sweep. A very large scope can exceed this in one run; a shorter cadence and tighter scope help. |
| One issue's field won't update | Muted goals are skipped by the write-back. Unmute the goal on that issue if it should be written. |
| Can't create a new field | Creating an instance-wide Jira custom field is a Jira-admin operation. A manageFields user without admin is told to map an existing field instead. |
Quartz also ships four read-only computed custom fields out of the box — Quartz SLA Status, Quartz SLA Target, Quartz SLA Remaining (min), and Quartz SLA Breached count. These resolve live per issue and need no sweep, so they are reliable for JQL and Automation when a mapped field is lagging.
AI features are greyed out
Every AI feature is part of the Advanced edition. Standard installs see them locked with an "AI: Advanced" lozenge — this is expected, not a fault.
Check the edition
In production, the Marketplace license is the only authority. A production install with no Advanced license is Standard, and no override can unlock AI. Check the "AI (Advanced edition)" card under Settings; upgrade via the Marketplace to enable the AI features.
Outside production: check the dev override
In development or staging only, an admin dev-override ('auto' / 'on' / 'off') can flip AI on for demos or off to verify the Standard lock. The override control appears in Settings only when the edition source is the dev-override. It has no effect in production.
Forecast and Governance are Advanced-only features. They are locked on Standard, so the fix is the Advanced edition.
If AI is entitled but a Rovo answer is missing, Rovo must be activated on the site for the agent to appear at all. On Standard the agent stays visible but inert, and its actions refuse with a message. See Rovo agent.
Still stuck? Contact support
If a problem persists after these checks, reach the Quartz team. Issue data never leaves Atlassian, so include the SLA name, the issue key, and a screenshot of the relevant panel or diagnostic to help us reproduce it.
| Channel | Where |
|---|---|
support@plugin-developers.com | |
| Support portal | https://plugin-developers.atlassian.net/servicedesk/customer/portals |
The admin-only Audit log is a useful first stop for "who changed what" questions — it records every SLA, calendar, permission, settings, mute, extend, and field change with actor and timestamp.
Was this page helpful? Yes · No · Contact support