All documentation pages
Rovo
Quartz adds an agent to Rovo Chat, Quartz SLA: "Ask about a request's SLA timers and which ones are about to breach." It answers questions about SLA timers in plain language, in the words Quartz's screens use, from the same figures the rest of Quartz counts.
Advanced. On the Standard edition the agent's actions answer that they need the Advanced edition. The agent needs Rovo to be active on your Atlassian site.
It answers as you. Every action reads only requests the person asking can browse in Jira, so two people asking the same question can get different answers. It answers from Quartz's own results: it does not read request content, and it is instructed to state only what Quartz's actions return, never to invent requests, numbers, dates or causes.
It answers only people with Jira product access. Quartz asks Jira who is asking before each answer, and uses a yes for at most 30 seconds. A customer of a service project with no Jira product access who reaches the agent is refused, in the same words a Jira user without access to that request, to Radar or to Reports gets, and is told nothing about SLAs.
What you can ask
Rovo offers two questions to start with: "What SLAs are about to breach?" and "Is this request going to breach its SLA?".
The agent has three actions and chooses one from your question.
| Action | Ask it | It answers |
|---|---|---|
| Get a request's SLA timers ("The SLA timers on one Jira request and their status, by its key.") | "What is the SLA status of SUP-4112?" | Each SLA timer on that request: its state, its goal, the working time used and left, and when it is due, in the same words as the request panel. You must be able to browse the request. |
| List SLA timers at risk ("Open requests whose SLA timers are at risk or about to breach.") | "What breaches in the next 8 hours?" | Open SLA timers that are breached, critical or at risk, most urgent first (breached, then critical, then at risk, each with the earliest deadline first), at most 15. Optionally only those due within the next 8, 24 or 48 hours, the breached ones included. You need View Radar. |
| SLA report ("Answer questions about SLA results over a date range, such as counts, met rates and where breaches concentrate.") | "How did Time to resolution do last month?" | Counts and met rates over a period, optionally for chosen SLAs, one outcome (met, breached or measured), or grouped (for example by priority, assignee or request type), with the lowest groups and a link that opens the matching view in Reports. You need View Reports. |
Periods the SLA report understands
Last 7, 30, 90, 180 or 365 days, this or last month, this or last quarter, a month ("August 2026"), a span ("1 to 31 August 2026", "2026-08-01 to 2026-08-31"), "since 1 August 2026", a year ("2025"), today, yesterday, "last N days" and "last N months". Periods are read in your site's time zone. A period it cannot read falls back to the last 30 days, and the answer says which period it read; a period before the history Quartz holds is refused with the first day you can ask about.
Good to know
- An SLA name the site never had is answered with the names it does have. A deleted SLA's history is still answered.
- When your View Reports grant is limited to some projects or SLAs, the answer counts only those and says which part of the site it covers.
- A period too large to answer at once returns the link to Reports, where the report is built with progress.
- The answer names, once and last, that it counts only requests you can browse.
- An outcome in the question ("how many breached") narrows the link it offers ("Open the breached ones in Reports"), while the counts keep their whole total.
Limits
The agent's answers count toward the same per-person limits as Radar and Reports. A report it cannot count in time returns the link to Reports (above), and a list of SLA timers at risk that Quartz could not check in full comes with the note "Partial results: Quartz could not check every open request in time." When Quartz cannot read Jira just now (Jira's hourly limit for apps was reached, this site has used its share of it, or Quartz is keeping the rest for more urgent work), an action says so and when to ask again, for example "Quartz is holding back because this site has used its share of Jira's hourly limit for apps, so I could not count these SLA timers for you just now. Ask me again after 15:00.", never that a request was not found, that nothing is at risk, or that a period is too large. While Jira's own hourly limit for apps is spent, Quartz may not be able to check who is asking, and the agent then answers as it answers anyone without access, until the limit resets. See Limits and data retention.
Something unclear or wrong on this page? Contact support.