Quartz 5 release notes

Released on 5 October 2026. Atlassian numbers this release 5.0.0, as Atlassian Administration and the Marketplace show, and its later updates 5.1.0 and on.

The foot of Quartz's Help menu shows the number your site runs, for example "Quartz 5.1.0 · Advanced edition".

Updates

5.4.0, 14 October 2026. Atlassian applies it by itself; nobody needs to approve it.

• Quartz's usage analytics note each action taken in Quartz, such as saving an SLA or recording an exception, marked with your site and the state of its subscription. They still never carry request content, names, email addresses or account ids, and your Atlassian administrator can still turn them off.

5.3.0, 13 October 2026. Atlassian applies it by itself; nobody needs to approve it.

• The row of pages starts with the Quartz mark, which opens your home page, and each page has its icon. The page you are on is a raised tab that slides when you move to another page.
• Radar has no separate bar above the lead any more. Re-scan sits at the end of the scan line, beside when Radar last scanned, and its radar turns while it reads.

5.2.0, 6 October 2026. Atlassian applies it by itself; nobody needs to approve it.

• Quartz's own sentences say exactly what it does, as these docs do: a backup is saved before each change to the configuration and before each import and restore; lifting an exception needs Record exceptions only; fields and alert rules follow a change within about a minute; an SLA's description takes up to 2,000 characters, as Quartz saves it.
• The backups page counts pinned backups first ("3 pinned and 8 more from the last 60 days"), and an object deleted since a backup reads Deleted.

5.1.0, 5 October 2026. Atlassian applies it by itself; nobody needs to approve it.

• Every screen, email and file names this version Quartz 5, after Atlassian's own number, and the foot of the Help menu shows the exact number your site runs. 5.0.0 called it Quartz 4.0.
• On a calendar's page, each time field is only as wide as a time, so a day's two times sit side by side in the Working week card.
• Radar's key reads its note about a measure-only SLA, and its note about SLA timers with no date set, as one sentence each. They were drawn in three columns around their number.
• On Reports, the Breached tile says what its SLA timers are counted among, for example "Of 2,148 SLA timers with a goal." It said "On 1,236 requests", which counted the requests of every SLA timer in the range, not only the breached ones.

In short

Quartz 5 is a new major version. The whole Quartz page in Jira (Apps > Quartz) is rebuilt as one app, and every screen now reads Quartz's own record of every SLA timer on your site instead of reading Jira again for each person on each visit. Jira's own events bring every change into that record, so Radar, Reports, Compliance, Forecast, the SLA fields and the alerts all count the same SLA timers, with no limit per SLA and no sample.

What that means for you:

• Every count is whole. Radar draws every open SLA timer on the site that you can browse. Reports counts every SLA timer that stopped in any range your history covers, and always reads the period before it.
• Numbers agree everywhere. The request panel, Radar, Reports, the SLA fields, the gadget, the portal and Rovo measure a request with the same engine: the same goal tier, the same calendar, the same extension, the same pause.
• Fields and alerts are current. A change on a request reaches Quartz, its fields and its alerts typically within about a minute. A breach is written and mailed close to its moment, not at the next hourly run.
• New pages and choices: alert rules, time in status, a report builder, schedules and Report history, exports to Excel and PDF, country public holidays, working-time schemes, calendar versions, permission scopes, a configuration file you can import anywhere, and a searchable Audit log.
• One set of words. Every screen, field value, email and file says SLA timer, request, breached, critical, at risk, on track, paused, met and measured.

Because Quartz 5 adds two permissions and a database, Atlassian asks an admin to approve the upgrade once. Until then, your site keeps running the version it has.

Before you approve the upgrade

Why Quartz 5 is a major version

Atlassian asks an admin to approve a new major version of an app before a site moves to it. Quartz 5 uses two new permissions and one new kind of storage. Atlassian's update window lists what it asks you to approve; on the first sites updated it named the second permission only ("create, modify and delete app properties data"), and Quartz holds both once the update is approved:

Quartz still does not ask to change projects or screens, or to list your customers. It shows which projects a field is missing from, and links to Jira's own screen settings.

Quartz 5 runs only while the site's Quartz subscription is active

The previous version kept working on a site whose trial had ended or whose subscription had been cancelled. Quartz 5 does not. On such a site every Quartz page says "Quartz's subscription is not active on this site.", the four built-in fields show no value on a request, and Quartz stops measuring, writing fields and sending alerts until the subscription is active again. Nothing stored is deleted, and a Jira admin can still download the site's configuration from that page. So before you approve the upgrade, check that Quartz has an active subscription or trial on the site: in Atlassian Administration, under Connected apps, Quartz shows its edition.

Where to approve it

In Atlassian Administration, under Connected apps (Jira's Manage apps page points there), open Quartz and approve the update. As soon as it is approved, Jira tells Quartz, and the update starts in the background. Nobody needs to wait for it: every page opens at once and says how far the update has got.

Going back is not supported

Once a site runs Quartz 5 and someone uses an option only Quartz 5 has (for example an SLA JQL filter, a working-days goal, a country's public holidays, a second alert rule or a scoped grant), the previous version would measure those SLAs wrongly. Going back to the previous version is therefore not supported. A problem found after the release is fixed in a later update of Quartz 5.

Before anything changes, Quartz saves a backup of your whole configuration as it was and pins it, so it stays until a Jira admin unpins it. You find it in Settings > Export, import and backups, as the row that reads Saved before the Quartz 5 update with a Pinned mark.

What happens when your admin approves

The update runs by itself, in the background. You can keep working.

1. A pinned backup of the configuration as it was (its row reads "Saved before the Quartz 5 update").

2. Your configuration moves to one stored object per SLA, calendar, holiday scheme, SLA field and alert rule. A site can now hold up to 2,000 SLAs. A save refuses an object that is too large (an SLA above 64 KiB, a calendar or a scheme above 220 KiB), and the refusal names it. Measured on a test site holding 507 SLAs and 203 calendars (a 5 MB configuration): every page and the request panel opened with no error.

3. Your settings carry over:

   • Company holidays become a holiday scheme called Company holidays, used by every calendar that used them. A calendar's own holidays become a scheme called <calendar name> holidays. Nothing a calendar closes on changes.
   • One calendar is marked Default for new SLAs: the one that was the default, else the first calendar.
   • An SLA whose reset was set to restart keeps measuring exactly as it did: its "On a reset" setting now reads "Invalidate the earlier cycles", and the Audit log lists every SLA this changed in one "Updated Quartz" entry (from "Restart the SLA timer" to "Invalidate the earlier cycles, as it measured before this update"). A new SLA can use a real restart.
   • Breach alerts become the first alert rule, Breach alerts, with the same levels, recipients and email.
   • Field updates: an hourly setting becomes As requests change; a setting of 3, 6, 12 or 24 hours becomes Every so often at the same interval.
   • Timer display formats carry over to the six formats Quartz 5 offers. A format with seconds now stops at minutes, and the two digital forms read as hours and minutes (34h 30m).
   • Permissions carry over. The previous version's one grant to extend and to mute becomes two grants, Extend SLA timers and Record exceptions, and every group or person that held it holds both. Everyone with Full configuration also holds Export, import and backups. Export reports starts open to everyone who can view Reports. View configuration and View the audit log start with nobody beyond who could already do those things. Project admins manage SLAs for their own projects starts off.
   • The audit log carries over. Extensions and exceptions recorded before Quartz 5 move to Governance; an entry made for several requests at once becomes one record for each request.
   • Your saved report views carry over as private views of the person who saved them.

4. Quartz reads your site's history once. Open requests first, so Radar, the fields and the alerts are whole early, then resolved requests, newest first, as far back as your history setting (12 months by default). Every page that counts says how far this has got, for example:

   Quartz is still reading this site's history: 41,000 of about 96,000 SLA timers. Counts grow until it finishes.

   The line counts SLA timers, so a request that three SLAs cover counts three times. How long this takes depends on the size of the site, on how many SLAs cover each request, and on Jira's hourly limit for apps (see Limits that stay). For 100,000 requests that one SLA covers:

   • On Jira's shared limit for apps (Tier 1): about 32 to 50 hours when the requests have a few changes each (about 26 hours when they have none), while the site does little else. The open requests come first, in about 3 to 10 hours. The read stops for the hour once the site has spent three quarters of its share of the limit, less what Quartz expects changes on requests and permission checks to need in the rest of the hour, so the rest stays for them and for your screens while it runs.
   • On a per-site limit (Tier 2, once Atlassian grants one; see limit 5): about 4.5 to 6 hours on a Standard site with 2,000 users.
   • Each further SLA that covers the same requests adds about 8 to 12 hours on the shared limit, and about 1.5 hours on a per-site limit, because Quartz searches each SLA's requests. Quartz reads each request only once, however many SLAs cover it.

   These times are extrapolated from 3,000 real requests read on a test site. The line never runs ahead of what Quartz has read.

   When the read waits, the line says why and when it goes on. There are three reasons: Jira's hourly limit for apps was reached, this site has used its share of that limit, or Quartz is keeping the rest of it for more urgent work (see Limits that stay, limit 5). Either way, the read goes on by itself.

   The first night after a large read never removes row detail: Quartz turns the oldest row detail into daily counts only when its database measures 90 percent full, never from a projection. Measured on a test site the night after a read of 3,000 requests, with 100,000 test SLA timers added: the database measured 46 percent, and no row detail was removed.

5. History is measured once under the Quartz 5 engine. From then on, an SLA timer that stopped keeps the result it was measured with. A later change to an SLA or a calendar applies to running SLA timers, unless the person who saves it asks Quartz to recount stopped ones from a date.

6. Nothing is mailed or written about the past. Reading history never sends an alert, and never writes a field value on a request that is already resolved. A breach the previous version already mailed is not mailed again. A breach Quartz 5 did not see happen is not mailed either: one on an SLA timer that was already running when Quartz 5 started, reached before Quartz 5 first read its request. That covers a breach reached after the previous version's last check, and one reached before the read of open requests came to that request. Only an hourly check that ran before the update had finished can still mail it. So after the upgrade, look at Radar for SLA timers that breached around it.

The words Quartz uses now

Every screen, field value, email, export and Rovo answer uses one vocabulary.

What changed from the previous version's words:

The built-in fields write the new words (Breached, Critical, At risk, On track, Met, Measuring, Measured, No date set, with ", paused" on a paused SLA timer). Breached, Critical, At risk, On track and Met are unchanged. A saved filter, queue or Automation rule written on the old words needs a look. Values change as Quartz rewrites them in the background, so for a while a search can return a different set of requests. The SLA Fields page says the same on its "Automation and JQL" card, and the field's own view reads both word sets.

Every page

The tab row has the same three groups: Monitor (Radar, Reports, Forecast), Configure (SLAs, Calendars, SLA Fields, Compliance, Governance) and Administration (Settings, Permissions, Audit log), plus Help. Each tab shows only to people who may open it. A deep link to a page opens that page, and Back and Forward move between Quartz pages as they do in Jira. Every time on a page is in the site's time zone (the default calendar's zone), and each person can choose Show times in my zone in the Help menu.

Radar

• Draws every open SLA timer you can browse, at the moment it breaches, with no limit per SLA. Counts are in SLA timers: "406 SLA timers across 392 requests (one timer per SLA on each request)".
• Times are in the site's zone, and the footer names it.
• A paused SLA timer on a working-time goal has no fixed deadline: Radar draws it where it would breach if it resumed now ("breaches no earlier than 15:40 today, if it resumes now"), and that moment moves later for as long as the pause lasts. A date goal keeps its date, paused or not.
• A list of more than ten SLA timers offers Show all.
• Decide today cards: a pattern where one SLA owns the breaches, the busiest hour, and the SLA timer breached longest. On the Advanced edition the busiest-hour card can add the forecast for its SLA timers, for people who can open Forecast and within ten minutes of their Forecast page reading the history.
• Extend, Extend by another amount ("by N" or "to N from now"), Clear extension and Record an exception (with an optional end date) from any row, and a whole batch at once from the busiest-hour card ("Extend the 24 by 2 working hours"). A large batch runs in the background with progress, and the SLA timers it could not change are listed with the reason.
• When your site asks for reasons, each of these asks for one.
• "Last 7 days X% met" counts the SLA timers that stopped in the last 7 days, and equals the lead on Reports, because both read the same record.

Reports

• Four readings: Outcomes, By person, SLA timer detail and the new Time in status.
• Any range your history covers: Last 7, 30, 90, 180 or 365 days, this or last month, this or last quarter, or a custom range, read by the moment each SLA timer stopped (Stopped, whether or not its request is resolved) or by the day its request was created (Created). The period before is always read, and every count is exact. A Reports address opens the range it names, so a copied link reads the same period.
• No date set has its own tile and column: an SLA timer whose goal is a date on the request, stopped while that date was empty, is counted apart and in no rate.
• Group by up to three (SLA, person, priority, work type, project, request type, Organization, component, label, goal tier, calendar, or any Jira field), and draw two groupings as a matrix. Over time by day, week, month, quarter or year. On By person, Group people by person, Jira group or a team field.
• Median, average and 90th percentile working time, as tiles and as a chart over time.
• A target line and an Under target lozenge when an SLA has a target met rate.
• Reopen rate and Where breaches concentrate (status at breach, person, priority).
• A Custom chart of up to ten series, each with its own filters, and Compare with a second reading in the same chart and table. A series and the Compare reading can each have a JQL filter of their own, and each is counted through its own filter: Quartz checks every such filter with Jira before it counts.
• By request layout on SLA timer detail: one row per request and a column per SLA. A column picker that offers every Jira field.
• Saved views hold the reading (its filters, range, groupings, columns, sort, chart series and Compare) and live in the page address, so a copied link opens the same reading. In this release one grouping is not kept: Calendar. A view or a link opens without it, so choose it again on the page, and a schedule or a dashboard gadget of that view is not grouped by calendar. A view can stay private or be shared with everyone who can open Reports, or with chosen groups and people, and can name editors. A shared view always runs as the person who opens it.
• Export: CSV (separator, minutes or formatted durations, date format), Excel (typed numbers and dates, with a sheet that says what the file covers), Print or save as PDF, Chart image, and a Calendar file of open deadlines.
• Schedules (from More): run a saved view daily (every day or chosen weekdays), weekly or monthly, at a time in the site's zone. Recipients get a link through Jira, never the figures. Every run is stored in Report history, with the change against the previous run, and can be downloaded as CSV or Excel.
• Add to a dashboard places the Quartz gadget on a Jira dashboard, set to that view.
• Ask Quartz turns a question into filters on the page, and Summary of this report puts the page's figures into words (Advanced edition).

Forecast (Advanced edition)

• Scores every open SLA timer on a working-time SLA against your own resolved history: Already breached, Likely to breach, Could breach, Unlikely to breach, Not scored yet.
• Already breached counts every breached SLA timer, whatever its SLA's forecast, so it equals Radar's count. An SLA with no history to judge against (nothing with a goal stopped on it in the last 365 days), one Quartz is still reading, or one whose search Jira rejected is not scored: its SLA timers are counted under Not scored yet, and the page names the SLA with the reason.
• A cohort that is thin over 90 days is read over 180 days, then 365, and each row names the window it used. Check again always finishes.
• Views can be saved and shared, like Reports.
• Quartz scores every open SLA timer in the background and keeps the result, so opening the page reads the kept scores instead of scoring every SLA timer again. The header says when the history was read and when the SLA timers were scored ("history read at 14:30 today, SLA timers scored at 14:31 today"). The first time, the page counts Already breached at once and bands the rest the moment the scoring finishes.
• The kept scores take at most a tenth of what the site's database may hold. When a new scoring needs room, the scores viewed longest ago are removed first; a scoring that still does not fit is shown but not kept, and Quartz waits an hour before it scores in the background again, unless someone chooses Check again.
• Measured on a test site with about 2,300 open requests (about 9,000 open SLA timers): Forecast opened in 8 to 23 seconds, Quartz scored all of them in about 8 seconds, Check again finished in about 18 seconds, and a page opened again while Quartz scored showed its progress, never an empty result.

Getting started

• Four steps that tick themselves: create your first SLA, check your working hours, connect Jira Automation, see what Quartz measured.
• This site and this app: the details support asks for, with Copy these details, including the Quartz version, edition, installation date and how many SLA timers Quartz holds.

SLAs

• The list shows Live now counts in SLA timers for every SLA, a search over names, descriptions and scope words, filters (Project, Request type, Calendar, Goal type, Compliance control, Configuration problem, Changed by, Folder), a column chooser and folders.
• Five templates (Time to first response, Time to resolution, Incident resolution, Service request fulfilment, Security incident response), and Describe your SLA to have one drafted (Advanced edition).
• Scope by projects, request types, work types, priorities, Organizations, components and a JQL filter.
• Timer rules by presets or your own: request created, resolution set, cleared or changed, assignee set, removed or changed, priority changes, status enters or leaves, status category changes, a field changes, a date is reached, a comment is made (public or internal; by anyone, the reporter, anyone but the reporter, an agent of the service project, the assignee, named people or groups), another SLA timer. Pause when all or when any pause condition holds. Choose which cycle counts.
• Goals: working time, working days, from a field, a date field, or no goal. Round the deadline up to the close of the working day. Keep the goal the SLA timer started with, or follow priority and tier changes. Thresholds as a percent or as time left. An optional Target met rate.
• Goal tiers by priority, request type, work type, label, component, Organization, assignee, assignee in a group, any field, or JQL, each with its own calendar. Calendar rules and Calendar from a field.
• Preview (what this draft measures, read as you) and Dry run (every request resolved in the last 30 or 90 days, measured with the unsaved draft, nothing written). A dry run started by someone who is not a Jira admin does not check the JQL written into the SLA (its JQL filter, JQL tiers and JQL calendar rules), so it covers every request in the rest of its scope.
• A save that changes how SLA timers are measured asks whether Stopped SLA timers keep their result or to Recount stopped SLA timers since a date, with Also update the SLA fields and Send alerts for SLA timers this change makes breached as separate choices, both off by default.
• A JQL that changes with time, groups, sprints or versions is checked again every hour, and the editor says so.
• After Create SLA, the editor follows the read of the new SLA's requests to its end, or says at once that no request is in its scope yet.
• Configuration health says plainly when an SLA names a status or a priority this site does not have (a template or a file from another site can bring one in), and what to pick instead.

Compliance

• Which ITIL 4, ISO/IEC 20000-1 and SOC 2 controls your enabled SLAs put a timer on, with the evidence of a range you choose (Last 90 days by default; 180 or 365 days; this or last quarter; custom), read by the moment each SLA timer stopped, as in Reports.
• Counts are the whole site's. Records you cannot browse are counted but not listed, and the page says how many.
• Export CSV builds the whole evidence pack in the background.

Calendars

• Counted from every open SLA timer on this site: each calendar and scheme says how many SLA timers are open on it, and the number opens them.
• Date exceptions with several spans and breaks, and a yearly repeat.
• Holiday schemes shared by calendars: a country's public holidays from data bundled with Quartz (with regions and per-day opt-outs), rules for days that move every year (the fourth Thursday of November, days from Easter), ICS or CSV import, and Export as ICS (a calendar file of its closed days for this year, or this year and next, with every rule and country day worked out into real dates).
• Working-time schemes: shared hours a calendar counts on top of its working week (weekend on-call, year-end cover).
• From when do the new hours apply? A change can start now, or on a day you choose; a day in the past counts SLA timers again from it.
• A day on this calendar means ...: set how long one d in a goal is.
• A move shows at once. When an SLA moves to another calendar, the calendar it moved to says how many of its open SLA timers the move carried and marks the SLA "moved here just now", before the SLA timers themselves are counted again.

SLA Fields

• Field updates: As requests change (the default: within about a minute of a change, and close to the moment a value changes with time) or Every so often (every 5, 15 or 30 minutes, every hour, every 3, 6 or 12 hours, or once a day). Pause field updates, and a freshness line that says what is up to date, what waits and since when (or until when, when Jira's hourly limit for apps holds it), and what Jira refused.
• Update fields now runs the whole site to the end with real progress (about 7 minutes for 3,000 requests on a test site; on Jira's shared limit a large run can wait for the next hour once the site has spent three quarters of its share, and then goes on by itself), and can also write final values on requests resolved since a date. When Jira refuses values, the result says so ("Refused" or "Partly written") with Jira's own reasons. The result also counts the values the run wrote into Quartz's four built-in fields, so a run that changed only those never reads "Nothing to update".
• Deleting an SLA field can clear its values on the requests first, in the background. Stop clearing stops it: the values already cleared stay cleared, the rest stay as they are, the Jira field is not moved to the trash, and the stop is recorded in the Audit log. The clearing waits while field updates are paused, however long the pause, and stops by itself if another SLA field starts writing into the same Jira field. A clearing that is still running shows on SLA Fields every time the page opens, with how far it got and Stop clearing, for everyone who may change that SLA field, not only on the visit that started it. While it is still looking for the requests that hold a value, it says so ("Searching: 5,000 requests found so far.").
• The example requests an SLA field shows ("What SLA deadline holds today") never read as none being open when Quartz could not check which of them you can open: the card says why, and when the examples show.
• Ten new value types: Started, Stopped, Paused since, Paused time, Time past the goal, Percent of goal used, Goal, Ever breached, Cycles and Goal name.
• Update Time remaining in automatic steps (exact at every threshold and at the goal) or every 5, 15 or 60 minutes.
• A field on no screen is still written. Quartz asks Jira to write past a field's edit screen and past a status that does not allow edits, which Jira's documentation allows only for an app whose app user is a Jira admin. A value written that way is read by JQL and Jira Automation; a person sees it on a request only where the field is on a screen. Where Jira refuses a value, Quartz counts it and quotes Jira's own reason.
• Where a Jira field can be written: its contexts against your SLAs' projects, Extend the field's context (Jira admins), which projects lack it on the edit screen, and how a Jira admin puts it there by hand. Quartz does not ask for Jira's permission to change screens.
• Search Quartz without setting anything up: every request Quartz measures while it is open carries Quartz's search property, and keeps it once resolved, so JQL like quartzBreachedCount > 0 or quartzNextDue <= endOfDay() works with no configuration. A request that was already resolved when Quartz 5 started reading your site's changes carries none. The property never holds an SLA name.
• Search by SLA name with quartzSla(), Quartz's own JQL function: key in quartzSla("First response", "breached"), or key in quartzSla("First response") for any state. It looks the name up inside Quartz, works in searches, filters, queues, boards and a scheduled Automation rule's JQL search, and finds only the requests each person can browse. key not in quartzSla(...) also finds the requests the SLA does not measure. SLA Fields writes it for the SLA and state you pick, beside the exact token form, which keeps working after the SLA is renamed and is the form an Automation rule's JQL condition takes: in a condition, quartzSla() matches nothing and shows no error (measured on a test site). The recipe Check an SLA timer in a rule's JQL condition writes it for you.

Governance (Advanced edition)

• Computed for any range: extensions, exceptions, cleared extensions, requests touched, the people who recorded them, and five patterns worth a second look. A record carried from before Quartz 5 that names no SLA says so.
• Exceptions in force now, the reason each person gave, and a filter for entries recorded without a reason. Export CSV.

Settings

• Configuration health checks calendars, SLAs, SLA fields, permissions and settings, and each problem opens the page it is fixed on. A check that could not ask Jira is counted as skipped, never as a problem (see When Jira is slow or busy). Check again reads Jira again at most once a minute for the whole site and six times an hour for each person, and it may spend at most 2,000 points of Jira's hourly limit for apps an hour for the whole site (or one whole check an hour, on a site so large that one costs more); otherwise the card shows the last check and when it was made.
• Quartz's own upkeep tries again by itself. When a background run that removes Quartz's search property from requests no SLA measures, updates the customer portal panel, or updates the answers Jira keeps for quartzSla() searches fails, Quartz tries again after 1, 2, 4 and 8 hours, then once a day, from where it had got to. After five failures in a row, configuration health says so.
• Jira's hourly limit for apps, for the people who configure Quartz: the health card says how many points of that limit Quartz spent this hour and in the last 24 hours, and on what, most first ("This hour Quartz spent 3,120 points of Jira's hourly limit for apps, most on reading permission schemes (1,206), ..."). When work waited, a note says which rule held it back and why: Jira's limit was reached, this site used its share of the limit, or Quartz was keeping the rest for more urgent work. A wait is a note, never a configuration problem: there is nothing to fix in Quartz.
• Timer display: six formats, including decimal days and decimal working days.
• Customer portal: show SLAs to customers per SLA, under a name written for them or the SLA's own name, on every request type, chosen request types or none, and Hide SLA timers that have not started.
• Alert rules: see below.
• Extensions and exceptions: Require a reason for extensions and exceptions.
• How long Quartz keeps its records: history, audit log, alerts and backups, each with its own choice, and the card says what a shorter choice removes before you save. It also says how full Quartz's database is, measured once a day against this site's allowance ("Quartz's database holds 23 percent of what this site may store: 236 MiB of 1 GiB, measured on 30 Sep 2026."), and, once Quartz has 14 days of readings, when it would reach 90 percent at the usual growth. That projection is for information only: it never makes Quartz remove anything.
• Automation and bots: Ignore automation and apps makes timer rules ignore comments from Atlassian app accounts, such as Automation for Jira, and the card lists those accounts, read from Jira once a day. The switch is off unless someone turned it on. Accounts to ignore names accounts of your own whose comments timer rules ignore whatever the switch says.
• Edition and AI and The configuration file.

Export, import and backups

• Download the configuration as one JSON file: every section or the ones you choose, and optionally without this site's ids, for a file you import into another site. Quartz prepares the file when you choose Download, and saves it as soon as it is ready.
• Import a file: Quartz compares it object by object and lets you choose, for each one, Add, Replace, Keep this site's, Add as a copy or Skip. Add and update, keep everything else or Make this site match the file. A mapping step matches fields, request types, statuses, groups, calendars and SLAs by name, so a sandbox file imports into production. The app accounts Settings ignores (Automation for Jira, say) travel as app accounts and match this site's app accounts. A file that differs in nothing says so. Measured on a test site: a 5 MB file (500 SLAs and 200 calendars more than the site had) sent in 18 seconds, its comparison on the page about 33 seconds after the file was chosen, and its 700 objects imported in about 44 seconds; with them stored, every page kept opening.
• Automatic backups before each change to the configuration, Back up now, Pin, Compare with another backup, and restore by Make this site match the backup, Only add and change, never delete, or Put back one thing. A backup always holds a configuration that is saved whole: Back up now during a large change that is still being saved says "Quartz is still saving a large change to its configuration. Try again in a minute.", and the backup an import or a restore takes first waits for it by itself. Each person runs one comparison of a file at a time, and one of backups (a restore's comparison included): starting another of the same kind replaces the one before. A restore or an import deletes as many objects as it needs to. Measured on a test site: putting back the backup taken before that 700-object import deleted the 700 objects, 500 of them SLAs, in about 70 seconds, and a Make this site match the file import that deleted the same 700 objects (started by the test itself: the card offers that mode only for a file that holds something new or changed you can import) finished in about 70 seconds too. Pages opened every 15 seconds meanwhile all drew, and an SLA saved during the restore waited for it and then went in.
• Reading files and backups has limits of its own for each person (the documentation's limits page lists them), and Quartz says so in the words of files: "You have asked Quartz to read files or backups many times in a short while. Try again in a minute." A large download or comparison can use a person's whole minute by itself, so the page waits for the next minute and goes on by itself, keeping what it has read: "... so it goes on preparing the file by itself in a minute." A restore's choices are worked out on the page from one read of the backup, so choosing does not use the limit up.
• A configuration file whose object ids include a name every JavaScript object has built in (such as constructor, toString or __proto__) is refused whole, and nothing changes, for example "This file is not a Quartz configuration Quartz can read: a calendar has no id Quartz can store."
• When Quartz cannot read Jira for the rest of the hour (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 import or a restore does not start: the card says why, until when, and that nothing has changed. A comparison started then waits and goes on by itself at that time (or, when it cannot start at all, the card says when to try again), and an import or a restore already running waits the same way; nothing changes until it goes on.

Permissions

• New grants: Export, import and backups, View the audit log, View configuration, Export reports, and Extend SLA timers and Record exceptions as two grants.
• Limited to these projects or these SLAs, on every manage grant, Extend, Record exceptions and View Reports.
• Everyone except on View Radar, View Reports and Export reports.
• Project admins manage SLAs for their own projects (off by default).
• Check a person explains every answer, on one SLA if you pick one.
• Only Jira admins can change Permissions.
• Every change a person makes asks Jira at once who they are and what they may do. A page that only reads may use Jira's recent answer: whether the person is a Jira admin for up to 30 seconds, and their Jira groups for up to 10 minutes. So a Jira admin role taken away in Jira stops that person's changes at once and their reads within 30 seconds, and a change to someone's Jira groups reaches Quartz's read screens within 10 minutes. A refusal is always checked with Jira again first, so a right given in Jira works at once. A change on this page applies to every read and every change at once.
• The Jira fields a person can see. For someone who is not a Jira admin, Quartz reads the fields Jira lists to that person and uses that list for up to 10 minutes, in field pickers and for the field names configuration health shows. A save always asks Jira at that moment about the fields it names, so a field Jira has hidden from a person is never saved by them. A Jira admin sees every field, so for them Quartz reads the site's own field list.
• When Quartz itself holds back a permission check (see limit 5), the page says whose checks it is holding back, "for your account" or "for this site", and when it checks again; it never says Jira's limit was reached when it was not.

Audit log

• Filters by range, area, action, person, subject and text, run on the server over the whole log, with paging and Export CSV. Downloads of the configuration file and of backups are recorded too.

Help

• What's new in Quartz 5, shown once to each person on a site that ran Quartz before Quartz 5, and always there in the Help menu.
• Contact support, which opens the Quartz support page.
• Quartz documentation and Show times in my zone.

In Atlassian's app management

• In Atlassian Administration, under Connected apps, the menu on Quartz's row offers Configure (opens Settings) and Get Started (opens Getting started). Jira's own Manage apps page points there.

On the request, the portal, dashboards and Rovo

• The request panel reads the same record as Radar, so it shows the same state. It offers Extend this SLA timer by N or to N from now, Record an exception with an optional end date, and a reason field ("Reason (optional)", or "Reason" when your site requires one). When it cannot read Jira again just now (Jira's hourly limit for apps was reached, this site used its share of it, or Quartz is keeping the rest for more urgent work), it shows Quartz's last record with its time, and why, instead of an error. When it has no record of the request yet, or cannot read its working cycles, for the same reasons, it says so and when to try again ("Quartz is holding back because this site has used its share of Jira's hourly limit for apps, so Quartz could not read this request just now. Try again after 15:00."); anything else Jira did not answer reads "Jira did not answer just now. Try again in a minute.", never an error code. Dates and times read as on every Quartz page ("26 Sep 2026, 10:06").
• The portal can show customers the SLA timers of the SLAs you leave on, each under a name written for customers or the SLA's own name, in the customer's own time zone where the portal gives it. Its Service level panel appears only on a request with something to show: while the Customer portal card is off, which is how Quartz is installed, and on a request type the card leaves out, customers see no panel and no empty heading. When Quartz shows its last record because it cannot read the request again just now, the panel ends with the time of that record ("Updated at 14:37."); when it has nothing to show, it reads "We couldn't load the service level just now. Try again after 15:00." Customers are never told why.
• The gadget can show a saved Reports view. When it cannot check its figures just now, it says whose limit held it and when to try again, and draws no figure.
• Rovo (Advanced edition): the Quartz SLA agent ("Ask about a request's SLA timers and which ones are about to breach.") has three actions: Get a request's SLA timers, List SLA timers at risk, and the new SLA report, which answers report questions ("How did Time to resolution do last month?") from the same record, with a link to the matching Reports view. The agent answers in Quartz's words. It answers only people with Jira product access: a customer with no Jira product access who reaches it is refused, and is told nothing about SLAs. When Quartz cannot read Jira just now, an action says so and when to ask again, 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. When it is Quartz that is holding back its permission checks, for the person or for the site, the agent says so and when to try again.

Numbers that change after the upgrade

Quartz 5 measures every request with one engine. Some numbers you saw before will move, because the previous version measured differently on some screens:

1. Extensions count everywhere. Reports, Forecast, the SLA fields, the built-in fields and the gadget now apply an extension recorded on a request. Before, some of them measured that SLA timer without it.
2. JQL goal tiers and a tier's own calendar count everywhere. Before, some screens measured such a request on the SLA's default goal or calendar.
3. A date with no time is due at the close of that day on the SLA's calendar, or at the close of the last open day before it when that day is closed. A deadline never moves later.
4. An SLA with no goal counts as measured, not met. It never breaches and is in no met rate. Met rates count met and breached SLA timers only.
5. An open SLA timer is never breached in a chart or a rate. Reports count outcomes of SLA timers that stopped; running ones are counted separately as running.
6. The Breached count field counts every breached SLA timer on the request, running or stopped. Before, it counted running ones only.
7. An extension on a date goal is working time on the SLA's calendar. Before, it moved the date by calendar minutes: an extension of 8 hours on a 9 to 17 calendar now moves the date by one working day.
8. Time remaining on a date goal counts every minute to the date, because a date is a moment.
9. Resets measure as they did. An SLA set to restart on a reset keeps its numbers (see What happens when your admin approves).
10. History is measured once under the Quartz 5 engine at the upgrade; after that, stopped results hold unless someone recounts them.
11. Radar counts every SLA and every open SLA timer. Before, a scan read a limited number of requests per SLA and said so when it was cut.
12. Reports read any range your history covers, whole. Before, a range was read live and long ranges were limited.
13. Times are in the site's zone on every page, Radar included. Before, Radar used your browser's zone.
14. Alerts cover every enabled SLA. Before, alerts followed the SLAs your SLA fields read. Alerts now wait for the current deadline, so an extension moves the moment an alert waits for, and a later, worse level against that deadline mails once.
15. Alert limits: recipients may include up to 50 groups (before, 10) and 200 named people, and Most alerts per check accepts 1 to 1,000 (before, up to 200).
16. Time remaining in an SLA field moves in steps, exact at every threshold and at the goal (see below).
17. The gadget's success rate counts met out of met and breached; SLA timers measured with no goal are listed apart.

The fields on the request

The four built-in fields are current

Quartz SLA Status, Quartz SLA Target, Quartz SLA Remaining (min) and Quartz SLA Breached count now fill themselves in the background: Quartz writes them each time an SLA timer on the request changes state, so they are current on the request and as columns in Jira's searches, queues and boards. Between those changes Quartz SLA Remaining (min) holds the minutes left at the last one; for minutes that move, search quartzMinutesLeft. They are read only. For a Jira Automation rule that acts on a change, an SLA field (a real Jira field Quartz writes into) is the route, and Quartz's search names (quartzMinutesLeft, quartzBreachedCount and the others) with the quartzSla() function are the route for JQL with no setup.

Jira's field list describes each one in the same words, for example Quartz SLA Target: "The earliest deadline of an SLA timer running on this request (a paused SLA timer has none), written by Quartz each time an SLA timer on it changes state." Quartz writes a built-in value only when Jira would show it differently, so an unchanged Quartz SLA Target adds no entry to a request's History. Measured on a test site: no such entry on 14 requests in more than ten hours of writes.

A paused SLA timer has no deadline

While an SLA timer on a working-time goal is paused, its working time left holds still and the moment it would breach moves later with every working minute the pause lasts, so it has no fixed deadline. While every SLA timer with a deadline on a request is paused, Quartz SLA Target is empty, an SLA field of value type Deadline is emptied, and quartzNextDue holds nothing, so a search like "SLA deadline" < now() never finds a request only because it waits. Quartz SLA Remaining (min) keeps its minutes left, and the status reads ", paused" ("On track, paused"). When the SLA timer runs again, Quartz writes its new deadline. A date goal keeps its date, paused or not. On Radar, Forecast and Reports' running SLA timers, a paused one is drawn where it would breach "if it resumes now".

Quartz's search property holds no SLA name

Every request Quartz measures while it is open carries Quartz's search property, and keeps it once resolved, so JQL can find requests by SLA state with no setup; a request that was already resolved when Quartz 5 started reading your site's changes carries none. It holds the worst state, the next deadline, the minutes left, the breached count, one opaque token for each SLA and state, and, on a request whose portal panel has nothing to show, the word hide. It never holds an SLA name: who can read a request's properties is decided by Jira and by every other app on your site, not by Quartz, so names stay inside Quartz. A search by name goes through quartzSla(), which looks the name up inside Quartz and follows a rename at once. The tokens belong to this installation of Quartz, so a token from before a reinstall never matches an SLA of the new one, and Quartz removes the property from requests it no longer measures.

SLA fields write within about a minute

As requests change is the default: a field is updated within about a minute of a change on the request, and a value that changes with time, like Time remaining, moves close to the moment it changes. Every so often writes on a schedule instead; the SLA timers themselves stay current either way. A value is written only when it changed, and every mapped field of one request goes to Jira in one write.

A field does not have to be on a request's screen for Quartz to write it: Quartz asks Jira to write past the edit screen, and past a status that does not allow edits, which Jira's documentation allows only for an app whose app user is a Jira admin. JQL and Jira Automation then read the value on every request; a person sees it on a request only where a Jira admin has put the field on the screen. Where Jira refuses, SLA Fields names the projects and quotes Jira's reason.

Time remaining moves in steps

Every write is a Jira write, so a value that changes with time moves in steps, not every minute. Automatic steps (the default) are exact at every threshold the SLA sets and exact at the goal; between them the value moves every 5 working minutes while the next threshold is less than an hour away, every 15 minutes under 8 hours, every hour under 3 days, and once a working day beyond that. You can choose every 5, 15 or 60 minutes instead. A search on a threshold (at risk, critical, breached) turns true close to the moment the SLA timer reaches it, not at a later step.

Final values

When a request is resolved, Quartz writes its final value once. A request resolved before an SLA field existed, or before Quartz 5 started reading your site's changes, carries no final value until someone runs Update fields now with Also write final values on requests resolved since a date. That run does not write Quartz's search property on them.

Breach alerts become alert rules

• A rule watches every SLA, chosen SLAs or chosen goal tiers.
• It acts when an SLA timer reaches a level (at risk, critical, breached), a set time before the goal, while it is still breached after the goal (again at a pace you set, a set number of times, until it is met), when it is met, or when it starts.
• It can email through Jira (assignee, reporter, watchers, groups, people), add an internal note, or reply to the customer on requests of a service project. A rule writes notes and replies only once a Jira admin has saved it, and a reply only for an SLA the Customer portal card shows to customers.
• A message template with placeholders ({request}, {sla}, {state}, {due}, {left}, {assignee}, {link}), and Try it on a request to preview it on a real request without sending.
• A rule never acts twice for the same moment of the same SLA timer. Switched on, it tells only about moments from then on.
• A paused SLA timer's moment "before the goal" moves later with the pause, so the rule acts on it only once the SLA timer runs again. A message's {due} reads where it would breach if it resumed now, at the send.
• The alerts Quartz sent keeps every send and every refusal, with Jira's own words, searchable by request key, result and rule, for as long as you choose (12 months by default).
• Quartz's own notes and replies never start, pause or stop an SLA timer.
• An SLA timer left out by an exception is never alerted, and neither is one that has not started.
• Email goes through Jira's own notifications, so Jira's permissions apply: a person who cannot browse the request is not mailed.

How fresh the numbers are

• A change on a request reaches Quartz, its fields and its alerts typically within about a minute (Jira's event delivery, then Quartz's own processing). Measured on a bulk edit of 500 requests: each request's built-in fields showed its new state within 10 seconds of Jira applying the edit (Jira itself took 2 minutes 51 seconds for the 500). After a large bulk change, Quartz's search names can follow later, up to about 20 minutes in that test, and up to about an hour and a quarter after the first read of a site's history (3,000 requests), because Jira runs one bulk update of properties at a time on the same requests. Radar, the request panel and the built-in fields are current meanwhile.
• A change that time alone causes (at risk, critical, breached, a Time remaining step, an alert before the goal) is written close to its moment. Measured on a test site, time-driven changes to Quartz's search names landed between a few seconds and about a minute after their moment. A value that changes with time moves in the steps its SLA field chose.
• A change Jira's events did not bring is caught by Quartz's hourly check. A change caused only by time passing inside a JQL with relative dates, or by a group, sprint or version change, is caught by the hourly re-check.
• When Jira's hourly limit for apps is reached, when this site has used its share of it, or when Quartz is keeping the rest of it for more urgent work, the held work waits, and Radar's scan facts and the coverage lines say which of the three it is and until when. The freshness line on SLA Fields says when Jira's own limit holds field values, and until when, and a waiting Update fields now run says when it continues. A page says Jira's limit was reached only when Jira's own pool is spent. Changes on requests are the last to wait, and nothing that waits is dropped: it goes on by itself.
• You never wait for this: a row on screen whose request changed after Quartz last read it is read again while you look.

When Jira is slow or busy

Quartz reads Jira as it works. Sometimes Jira asks apps to slow down for a moment, and sometimes Quartz holds back its own reads because this site has used its share of Jira's hourly limit for apps (see Limits that stay, limit 5). Quartz stays usable through both:

• Pages answer in time and say why they wait. Every Quartz page, the request panel, the portal, Rovo, the built-in fields and quartzSla() stop waiting for Jira early enough to answer within the 25 seconds the platform gives one call, even when Jira answers slowly or not at all. Where Quartz holds back, Radar, Reports, Time in status, Forecast, Settings and the import and restore cards say whose limit it is and until when. Reports, for example, reads "Quartz is holding back because this site has used its share of Jira's hourly limit for apps, so Quartz cannot check which requests you can open until 21:00. Run the search again after that to count your SLA timers.", and its count reads "Not counted until 21:00." instead of a number nobody could check. A report or Time in status with a JQL filter is never counted without its filter while the check of that filter waits: it says so in the same words, and counts nothing until then; the same holds for a JQL filter on a Compare reading or on a chart series. A JQL filter Jira does not accept is said in Jira's own words, and a file that could not be built says why first (the check that waits and until when, or "That calendar no longer exists."), then "The file was not built. The rows on screen are still good." The request panel, the portal, the gadget and Rovo say a held read is held, and when to try again (see On the request, the portal, dashboards and Rovo). Where Jira asked Quartz to slow down, a page says "Jira asked Quartz to slow down for a moment". If Jira does not answer in time when Quartz checks who you are, the page says "Quartz could not check your permissions" and checks again by itself in a minute. The work that waits goes on by itself. Measured on a test site under heavy load (1,500 new requests, three rounds of 1,500 edits and two runs of Update fields now, until Quartz held back this site's share of the hour): 13 Quartz pages, each opened five times (before the load, under it, and while Quartz held back), all opened, and the slowest call took 5.8 seconds.
• The built-in fields never turn blank because Jira did not answer. Jira keeps the value Quartz gives it for Quartz SLA Status, Quartz SLA Target, Quartz SLA Remaining (min) and Quartz SLA Breached count, and searches, queues and boards read that value. When Jira does not answer a read Quartz needs to work a value out, Quartz gives the value it last recorded for that request, or else the value Jira already holds, never an empty value or one worked out from half the facts.
• Configuration health never calls something missing because it could not ask. When Jira could not be asked about a field, a status or a project, that check is counted as skipped, and the card says so: "... so it did not read projects, fields, field contexts, groups and accounts and 8 checks were skipped. Nothing here says a project or a field or a field context or a group or an account is missing; they run again once the limit lifts." SLA Fields does not call such a field gone, and saving an SLA field that keeps its Jira field is not refused. A field, status or project that Jira really does not have is still named.

What Quartz stores, and for how long

Everything below is inside Atlassian's Forge platform, in hosted storage; where it is stored follows the data residency Atlassian offers for Forge apps. You set four of these periods in Settings > How long Quartz keeps its records (SLA timer history, the audit log with the extension and exception records, the alerts Quartz sent, and how long every backup is kept), and each change is in the Audit log. The others are fixed, or follow one of those four.

Quartz's database (new in Quartz 5)

• Per request and SLA timer: ids and keys, instants, working minutes, project, priority, work type, request type, status and security level, and the account ids of the assignee and reporter; a request's labels, Organizations and components where an SLA uses them. For each comment added or edited on a request in a project an SLA measures, whether or not any SLA reads comments, and for each earlier comment on a request whose SLA reads comments: its id, when it was made, whether it was public, its author's account id and, where a comment condition asks, whether that author is an agent. The record of SLA timers never holds a summary, a description or a comment's text. (A report keeps the values of the Jira fields someone adds to it, which can include a text field such as the summary: see Jira field values below.) Stored for your SLA timer history setting: 12 months by default; 3, 6, 12, 24, 36, 60 or 84 months, or for as long as the request exists. The comment details of a request that no SLA measures are not removed by this setting, or when the request is deleted. When a site nears its storage, older detail is rolled into daily counts, so counts and rates stay exact while row detail and medians cover the most recent months, and the page says from which month. That happens only when the database measures 90 percent full, never from a projection: the oldest months go first, until the database is under 80 percent, and Quartz records it in the Audit log and in a note in configuration health. Measured on a test site: about 2.8 KB a request right after its history is read, so about 270 MiB for 100,000 requests, and more as they change, of the 1 GiB a production site holds.
• Every alert Quartz sent or Jira refused: 12 months by default (the same seven choices).
• The previous version's record of alerts already sent (request keys and SLA levels): the update copies it here, and Quartz carries each entry into that request's own alert memory, which stays while the request is in Quartz's record. The copy is removed about 30 days after its entry was carried over, or about 30 days after the update for an entry no SLA timer took up. The previous version's own entry in key-value storage is left as it was, until Quartz is uninstalled.
• Report history runs (each run's figures, with the display names of the people they are grouped by where it groups by person, its rows, with the values of the Jira fields its view names, and a copy of the saved view it ran, with the account ids of the view's owner, its editors, the people it is shared with, whoever last changed it and any person its filters name; a run someone started by hand also keeps their account id), for the SLA timer history setting; with for as long as the request exists, until someone removes the run (a run of a deleted view can no longer be removed by hand). A run keeps its rows after a request is deleted in Jira or leaves Quartz's record, and Quartz no longer shows those rows to anyone.
• Forecast's scores (Advanced edition): for each person who opens Forecast, one score for each open SLA timer they may forecast, with the facts of its request at the scoring (the same kinds as above). Replaced at each scoring, and removed about a week after that person last opened Forecast. They take at most a tenth of what the database may hold: when a new scoring needs room, the scores viewed longest ago are removed first.
• Jira field values read for report columns, groupings and filters (whichever field someone picks, a text field such as the summary included, up to 255 characters a value), while the request is in Quartz's record; a Report history run keeps its own copy for as long as the run is kept.
• How much of Jira's hourly limit and of the database time Quartz used, per hour and minute, this site's permission checks with Jira included: 30 days; what spent Jira's limit, per kind of call and per page or job: 7 days.
• A searchable copy of the audit log and of the extension and exception records, for as long as the records themselves (below).
• A person's checked access to requests, made when they open a page: 10 minutes, or until the end of the report or export that started with it, then removed at Quartz's next five-minute pass.

Quartz's key-value storage

A record below that expires is deleted by Atlassian's storage after its time, which can take up to 48 hours more.

• Configuration: SLAs, calendars, schemes, SLA fields, alert rules, views, schedules, permissions and settings, until you change or delete them. An SLA's earlier definitions, and a deleted SLA's last one, stay with who changed or deleted it until Quartz is uninstalled (when a restore puts a deleted SLA back, its last one stays as one of its earlier definitions), so the history measured under them stays reportable.
• Audit log entries and extension and exception records: 12 months by default (3 to 84 months).
• Backups: each backup for 60 days (settable to 365; at most the newest 100 of a day), then the newest of each day for 12 months, then the newest of each month while an audit entry names it. Pinned backups stay until someone unpins them, and the newest backup while it is the newest.
• Unsaved drafts: until they are saved or discarded (cleaned up after a year).
• AI answers (Advanced edition): 30 days.
• The names Ask Quartz reads a question against (Advanced edition), for each person who asks: used for 5 minutes; they expire after a day.
• The figures from your resolved history that Forecast compares with (Advanced edition), for each person who opens Forecast: they expire a week after they were last worked out. A note of which of them that person last checked expires after a day.
• Jira's answer about who may use Quartz (whether a person is a Jira admin, their groups, the projects they may browse or administer): used only by pages that read, for at most 30 seconds, and the person's groups for at most 10 minutes; their name and time zone: 15 minutes. It expires after a day.
• Other facts Jira gave about people, under their account id: the Jira groups of an assignee or of a comment's author, when an SLA rule names a group (used for an hour, they expire after a day); whether a person is an agent of a service project (used for a day, it expires after 7 days); the display name of each person a report or Forecast names, and their Jira groups when a report groups people by Jira group (used for a day, they expire after 7 days); the display names of the people your configuration names (used for 5 minutes, they expire after a day).
• Small records that hold a person's account id itself, with no expiry, until they are replaced or Quartz is uninstalled: the SLA timers they marked reviewed on Radar (a request key and an SLA for each, at most 500, each mark used for a day), when they last ran a schedule by hand (their last ten such runs at most), their own choices on Quartz's pages (such as their time zone, favourite views and the notices they have seen), Radar's 14-day trend as Radar last read it from Jira for them (it does so for someone who may open Radar but not Reports, and when it could not check which requests a person can open; a trend Radar reads from Quartz's own record expires after a day), who started the last Update fields now, who placed each Quartz gadget on a dashboard, and who installed Quartz and who approved its last major update.
• When Quartz checks who may browse a project: the project's lead and the people and groups in its roles (used for 5 minutes) and the Browse grants of its permission scheme (used for an hour). They expire after a day.
• A request Quartz has just read for the request panel, the customer portal, Explain in plain words or the Rovo agent (its facts with its summary, and its history with the words before and after each change, an edited summary or description included, but not a comment's text): used for at most 30 seconds; it expires after 10 minutes.
• The Jira fields a person who is not a Jira admin can see (the names and types of the fields Jira lists to them): used for at most 10 minutes, and by Reports' column picker for at most 5; the list expires after a day. For a Jira admin Quartz keeps no such list.
• How many points of Jira's hourly limit each person's permission checks spent in the hour, under a one-way hash of their account id: it expires after two hours. How many groups Jira last listed for that person: it expires after a day. Counts of each person's recent use (reads of requests, new views of requests, JQL checks, Check again, file reads, checks of an SLA field's Jira field, reads of the fields they can see, uses of AI, configuration changes), under the same kind of hash, and how many points all such reads of field lists spent on the site in the hour: they expire within two days.
• When configuration health's Check again last read Jira, and what this site's checks spent in that hour: it expires after a day.
• For Quartz's own upkeep (removing its search property, the customer portal panel, the quartzSla() answers), how many runs in a row did not finish, when it tries again and where the last run got to, in that upkeep's own record (here, or in Quartz's database for the search property): cleared when a run finishes.
• A note of a Quartz gadget being added to a dashboard (the saved view, its title, the gadgets already there, and who added it): until Jira confirms the gadget; it expires after a day.
• A note of a field's context being extended when Jira did not answer in time (the SLA field, the projects, and who asked): until Jira shows the change and Quartz records it in the Audit log; it expires after a day.
• The members (account ids) of each Jira group an SLA names, which the hourly JQL re-check reads: the list it last read, kept with no expiry to compare with the next read, which replaces it; a copy used for an hour, which also holds the groups of a service project's Service Desk Team role when Quartz reads that project's agents from the role, and expires after 7 days; and, while a large group is read in parts, what was read so far, until that read ends (it expires after two days).
• The work Quartz runs in the background (a report, an export, a comparison, an import, a batch of extensions or exceptions): what it was asked, who started it, how far it got, and the rows or file parts built so far, which for some files, such as the Compliance evidence pack, include each request's summary. These expire within two days of the work's last step, but a batch of extensions or exceptions keeps its list of requests until the batch ends, 30 days at most. An Undo of extensions or exceptions leaves a note that the change was undone, with who asked, for 30 days.
• A note of a recount someone started from configuration health (from which date, and who started it): it expires after 30 days.
• The counters of the usage analytics: they expire within two days.
• How much room the records of checked access take, as Quartz last measured them: it expires after an hour.
• The quartzSla() searches Jira holds for your site: a fingerprint of the SLA name (never the name itself), the state asked for, and when Jira last confirmed it, so Quartz can send Jira a new answer when an SLA changes. It expires 30 days after Quartz last updated it.

When Quartz is uninstalled, Atlassian deletes its database and its key-value storage, with everything listed above. What Quartz wrote into Jira stays in Jira: the values in the fields you mapped, the notes and replies your alert rules wrote, and Quartz's search property on requests.

Limits that stay

These come from the platform Quartz runs on or from Jira, and Quartz states them wherever they apply:

1. One call answers within 25 seconds and 5 MB, and a request to Quartz carries at most 500 KB. Large results arrive in parts, long work runs in the background with progress, and files upload in parts. Quartz stops waiting for Jira in time to answer within those 25 seconds (see When Jira is slow or busy).
2. Quartz's own schedule runs at most every 5 minutes. Changes on a request come from Jira's events, usually within a minute, and time-based changes are written close to their moment through delayed background events.
3. Quartz's database holds 1 GiB per production site. History beyond what fits keeps exact counts and rates, while medians, percentiles and row detail cover the most recent months, and the page says from which month. Quartz does this only when the database measures 90 percent full, never from a projection, and stops once it is under 80 percent.
4. The first read of a large site's history after installing or upgrading takes time. Worked out from a read of 3,000 requests on a test site: about 32 to 50 hours for 100,000 requests on Jira's shared limit for apps, where the read stops for the hour at three quarters of this site's share, less what changes on requests are expected to need, so they and your screens keep the rest, about 4.5 to 6 hours on a per-site limit, and about 8 to 12 hours more (1.5 on a per-site limit) for each further SLA that covers the same requests. Every page shows how far it got.
5. Jira limits how much every app may read and write each hour, in points. Quartz 5 runs on Jira's shared pool for apps (65,000 points an hour shared by every site with Quartz, 16,250 of them this site's share). When Atlassian grants a per-site pool, Quartz uses it on its own, with no change on the site. Once the shared pool is spent, Jira refuses Quartz's calls on every site until the next hour, so Quartz holds each site to its share for everything but changes on requests, and one busy site cannot hold up every other site's screens. Inside the share, history, background checks and reports stop for the hour at three quarters of it, less what Quartz expects changes on requests and permission checks to need in the rest of the hour (the most of what they needed so far this hour, in the hour before, and at the same hour on the busiest of the last seven days), so the rest stays for them and for screens. Work already under way is finished, never cut part way, and jobs that waited for the top of the hour start again one kind after another, a minute apart, in a fixed order (changes on requests, the history read, Update fields now, the hourly and daily checks, the JQL re-check, then the rest). Quartz spends in order (changes on requests, screens, history, checks, reports) and keeps part of the pool for the more urgent work, so on very busy sites history, checks, reports and field values can lag. Pages that wait say why (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) and until when (a waiting Update fields now run says only when it continues), and the work goes on by itself; nothing is dropped. A heavy hour of one admin on a test site (every page three times, reloads, saves, import previews and a field run) spent about 5,000 points, about 30 percent of the site's share. Permission checks (Quartz asking Jira who a person is and what they may do) count toward the share and have limits of their own: 1,200 points a minute and 4,000 an hour for each person (more in more than 50 Jira groups, where each check costs more: up to 4,596 and 15,321 at 200 groups), and on the shared pool at most the site's share an hour for the whole site. On the shared pool a person in many groups gets the larger budget only while the site's checks stay 4,000 points under the site's limit, so no single account can use that limit up, and past the site's limit every person keeps their first 1,000 points of the hour (up to 3,830 at 200 groups), enough to keep Radar open. By our tests, a person in 50 groups spends about 800 points an hour on them with Radar open all hour, and about 1,150 opening a page every two minutes and saving now and then, so about 14 to 20 such people working in Quartz all hour reach the site's limit; Quartz then says it is holding back its checks with Jira for this site until the top of the hour, and each person keeps their allowance. Sites with many active Quartz users need a per-site limit. What the shared pool cannot rule out in this release, each clearing by itself and dropping nothing: (a) several background jobs part way through a page of work at once each finish it, so an hour can end a little past the three-quarter line, and if that passes the share, screens wait for the top of the hour; (b) a busy hour with no busy hour at the same time of day in the last seven days is not foreseen, so background work started early in it can leave screens waiting later in it; (c) two people in about 200 Jira groups who both work in Quartz all hour can reach the site's limit on permission checks late in the hour; (d) an account in about 200 groups that keeps calling Quartz just under its limit of a minute can spend the site's permission checks to within 4,000 points of the site's limit; (e) on a site with about 500 or more Jira fields, people who are not Jira admins can lose field pickers and field names for part of an hour once what the site may spend on reading the fields people can see is used up; (f) the hourly or daily check can be delayed by hours behind a large backlog of changes on requests; (g) a large Jira group read in parts over more than one hour misses a person who leaves it between two parts, until the next hourly re-check. A per-site limit (Tier 2) removes these: it has no share, no three-quarter line and no site limit on permission checks, it leaves several times the room for (e), and (f) and (g) arise only where background work has to wait. Search and permission reads also have short burst limits, and one request takes at most 20 writes in 2 seconds and 100 in 30 seconds.
6. A status that does not allow edits, or a field that is not on a project's edit screen, can refuse field writes. Quartz asks Jira to write past both, which Jira's documentation allows only for an app whose app user is a Jira admin; a value written that way is read by JQL and Jira Automation, and a person sees it on a request only where the field is on a screen. Where Jira refuses a value, Quartz counts the requests and quotes Jira's own reason.
7. Jira counts and searches only bounded queries, so JQL Test on an SLA that covers every project cannot count a query that is not narrowed to a project or a date range.
8. Email goes only through Jira's own notifications: no Slack, Microsoft Teams or outside email. Scheduled report emails carry a link, not figures. A Jira Automation rule watching an SLA field can post to Slack or Teams.
9. Jira's user search returns no total, so people pickers say "Showing the first 50".
10. Forge did not record who installed Quartz before Quartz 5. Getting started then shows the install date Forge gives, with no name, or, when Forge gives none, reads "Not recorded (installed before Quartz 5). In use since <date>."
11. A native Automation trigger and Jira Service Management's own SLA queue columns are not open to apps. Quartz offers its search names, its own JQL function quartzSla(), current fields and Automation recipes instead.
12. Quartz's search names are fixed in the app, and Jira limits how many app properties (Jira's entity properties) one request can hold across all the apps on the site; Quartz writes one, its search property.
13. Quartz does not ask for permission to change projects' screens or to list your customers' Organizations. It shows where a field is missing and links to Jira's settings, and suggests Organizations through JQL.
14. Losing Browse permission hides rows on screens within 10 minutes. A report or export already running finishes with the access its person had when it started, because background work cannot check again as that person. Losing a Jira admin role stops that person's changes at once and their reads within 30 seconds; a change to someone's Jira groups (a group that grants a Quartz permission taken away, or a group an Everyone except list names added) reaches Quartz's read screens within 10 minutes, and every change that person makes is checked with Jira at once; a change on Quartz's Permissions page applies at once. Which Jira fields a person who is not a Jira admin can see is used for up to 10 minutes in field pickers and field names, and a save always asks Jira at that moment; a Jira admin reads the site's own field list.
15. A development install of Quartz holds 128 MiB of database, so a large site is measured on a staging or production install.
16. Quartz's database answers one read within 5 seconds and one write within 10, and gives each site 62.5 seconds of statement time a minute. Large changes run in chunks, and heavy reports yield to changes on requests, so a large report can take longer in a busy minute. Measured on a development site: a Last 365 days report drew in 23.7 seconds over a table of about 114,000 SLA timer rows, of which it counted the 2,162 real SLA timers (the rest were synthetic test rows, which Reports never counts); its CSV was saved at once and its Excel file in about 13 seconds. A report that counts 100,000 real SLA timers has not been measured yet. A large report runs as a background job, with its progress on the page (you can leave the page and come back, or stop it); a scheduled run of a saved view is kept in Report history.
17. The platform allows 1,000 background steps from one start; Quartz's long jobs continue from where they stopped at the next five-minute pass.
18. A Time remaining value in a Jira field moves in steps, not every minute, because every write is a Jira write. The steps are exact at every threshold and at the goal, and each SLA field can choose finer ones.
19. In an Automation rule's JQL condition, quartzSla() matches nothing and shows no error, even though the condition's own check of the query says it finds requests (measured on a test site); a JQL condition takes the exact token SLA Fields writes. Jira shows a quartzSla() mistake (a state it does not know, say) on its search page; a rule, a script or Jira's REST search with the same mistake can find no requests and show no error, as Jira's REST search did on a test site.
20. Jira runs one bulk update of app properties at a time on the same requests, so after a large bulk change, or the first read of a site's history, Quartz's search names (and quartzSla()) can follow later than a single change: up to about 20 minutes after a bulk edit of 500 requests, and about an hour and a quarter after the first read of 3,000, on a test site. The built-in fields, Radar, the request panel and every other Quartz page are current meanwhile.
21. The largest configuration Quartz was measured with holds 507 SLAs and 203 calendars (a 5 MB configuration file, each calendar with about 150 holidays). On a test site every page and the request panel opened with it, with no error; the request panel took 11 to 12 seconds, against 2 to 4 seconds with the site's own 7 SLAs. A site can hold up to 2,000 SLAs and 1,000 calendars (the limits page lists every ceiling), far more than this.

Privacy

Quartz runs on Atlassian's Forge platform: your requests are read and measured inside Atlassian, and everything Quartz stores is in Atlassian-hosted storage. The only data Quartz sends outside Atlassian is usage analytics (which Quartz pages, features and actions are used, marked with your site and the state of its subscription), sent to an analytics product on Atlassian's pre-approved allowlist; it never carries request content, SLA values, names or email addresses, and your Atlassian administrator can turn it off in Atlassian Administration. The AI features of the Advanced edition run on Atlassian-hosted models. The details are on the privacy page of the documentation, https://plugin-developers.com/quartz/docs/security.html, and in the privacy policy, updated for Quartz 5: https://plugin-developers.com/quartz/privacy.html

Fixed in this release

• Every screen now reads the same SLA timers, so the counts on Radar, Reports, Compliance, Forecast, Calendars, SLA Fields and the SLA list agree.
• A breach alert no longer depends on which SLAs an SLA field reads.
• A breach the previous version already mailed is never mailed again.
• A group renamed in Jira holds on to its grants in Quartz, because grants name groups by their Jira id.
• Two people saving two different SLAs a moment apart both succeed. When two people save the same SLA, the second is told someone saved it after they opened it, and loses nothing.
• Leaving a page with unsaved changes asks first, and changes that could not be saved are held as a draft you can restore.

Something unclear or wrong on this page? Contact support.