Limits and data retention

This page lists how current Quartz's numbers are, the limits that come from Jira and from the platform Quartz runs on, the limits Quartz sets itself, and how long Quartz keeps its records. Wherever a limit applies, the screen says so in place.

How current 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 test site: after 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 took 2 minutes 51 seconds for the 500).
• Quartz's search names can follow a large change later (limit 20 below): up to about 20 minutes after that bulk edit, and about an hour and a quarter after the first read of 3,000 requests.
• 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 work has to wait for Jira's hourly limit for apps, the held work waits and goes on by itself (see When Jira's hourly limit runs low). The freshness line on SLA Fields, Radar's scan facts and the coverage lines say why and until when. Changes on requests are the last to wait.
• You never wait for this: a row on screen whose request changed after Quartz last read it is read again while you look.

The first read of your history

After Quartz is installed, or a site upgrades to Quartz 5, Quartz reads the site's history once: open requests first, then resolved requests, newest first, as far back as your history setting. Every page that counts says how far it has got, and never runs ahead of what Quartz has read. How long it takes depends on the number of requests, on how many SLAs cover each request, and on Jira's hourly limit for apps:

These times are for requests that one SLA covers, worked out from 3,000 real requests read on a test site: Quartz read about 1,000 requests a minute, and every request was in its record about 4 minutes after the read began. What decides the time is how many points of Jira's hourly limit for apps the read costs, not Quartz's own pace: about 3 points a request, about 4 when it has a few changes, and about 1 more for each further SLA that covers it, because Quartz searches each SLA's requests. Quartz reads each request only once, however many SLAs cover it. On Jira's shared limit those points come out of this site's share of the limit (see below). The read stops for the hour once the site has spent three quarters of that share, 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. Everything the site spends in the hour counts toward that line, so the read goes fastest while the site does little else, and on a busy hour it reads less. Radar, the fields and the alerts are whole once the open requests are read.

Reading history never sends an alert and never writes a field value on a resolved request.

The nightly size check after a large first 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 (see How long Quartz keeps its records). 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.

When Jira's hourly limit runs low

Jira limits how much every app may read and write each hour, in points. By default one pool of 65,000 points an hour is shared by every site that runs Quartz, and once it is spent Jira refuses until the next hour. A site gets a pool of its own only after Atlassian's review. Quartz spends that pool with care:

• Changes on requests come first, and Quartz never holds them back itself. Then screens, then the history read, then background checks, then reports. Each of those keeps part of the pool for the work above it (a tenth, 40 percent, half and 60 percent, less as the hour runs out).
• On the shared pool each site has a share: a quarter of it, 16,250 points an hour, for everything but changes on requests, so one busy site cannot hold up every other site's screens. With a per-site pool the share goes away.
• Inside the share, background work leaves room for screens and for changes on requests. The history read, background checks and reports stop for the hour once the site has spent three quarters of its share (12,187.5 points), less what Quartz expects changes on requests and permission checks to need in the rest of the hour. It expects the most of three things: what they needed so far this hour, what they needed in the hour before, and what they needed at the same hour on the busiest of the last seven days. Work stopped this way waits for the top of the hour. A piece of work already under way (one page of a search with what it found) is finished, never cut part way, and a large page is made smaller so it fits the room that is left.
• Work that waits goes on by itself, the most urgent first, at the top of the hour or as soon as the pool allows. Nothing is dropped. Background jobs that waited for the top of the hour start again one kind after another, a minute apart, always in the same order: catching up with changes on requests, then the history read, Update fields now, the hourly and daily checks, the hourly JQL re-check, then everything else. An earlier kind gets the room first.
• Pages say why work waits, and until when, in one of three ways: "Jira's hourly limit for apps was reached" (only when Jira's own pool is spent), "Quartz is holding back because this site has used its share of Jira's hourly limit for apps", or "Quartz is keeping the rest of Jira's hourly limit for apps for more urgent work". A waiting Update fields now run says only when it continues.
• Settings shows the spend. For people who configure Quartz, configuration health says how many points Quartz spent this hour and in the last 24 hours, and on what, most first. When something waited, a note says which of the three held it back. A wait is a note, never a problem to fix.
• Permission checks have limits of their own. Every page and every change asks Jira who the person is and what they may do; a page that only reads may use Jira's recent answer (see limit 14), and the calls a page makes together share one check. Quartz counts these checks in points of Jira's hourly limit for apps:
  • For each person: 1,200 points a minute and 4,000 an hour. A check costs more for a person in many Jira groups, so a person in more than 50 groups gets more, in step with what their checks cost: up to 4,596 a minute and 15,321 an hour at 200 groups.
  • For the site, on the shared pool: at most its share, 16,250 points an hour. The checks also count toward the site's share, like everything else Quartz spends.
  • On the shared pool, no single account can use up the site's limit. A person in many groups gets their larger hourly budget only while the site's permission checks stay 4,000 points under the site's limit; past that line they keep 4,000 points an hour, or six tenths of their budget when that is more.
  • Past the site's limit every person keeps an allowance: their first 1,000 points of the hour (up to 3,830 at 200 groups), which is enough to keep Radar open all hour, so the use of others never locks a person out of reading.
  • By our tests, a person in 50 groups spends about 800 points an hour on permission checks 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, fewer when they are in more groups.
  • Past a limit, a page says "Quartz could not check your permissions", and whether Quartz is holding back its checks with Jira for your account or for this site. It checks again by itself at the time it names (the next minute, or the top of the hour); the person's permissions do not change.
• Sites with many active Quartz users need a per-site limit (Tier 2). On the shared pool, the permission checks of a site where many people work in Quartz at once use up its share, and then its screens wait, and each person's permission checks are held to their allowance, until the top of the hour. A per-site limit has no such site limit. Atlassian grants per-site limits after its own review, and Quartz uses one on its own once it is granted, with no change on the site (limit 5).
• What the shared pool cannot rule out in Quartz 5. None of these drops any work, and each clears by itself, most at the top of the hour. A per-site limit (Tier 2) removes them: it has no share, no three-quarter line and no site limit on permission checks, so the first four cannot happen there; it leaves several times the room for the fifth; and the last two arise only where background work has to wait, which a per-site limit seldom makes it do.
  1. When several background jobs are part way through a page of work at the same moment, each finishes its page, so an hour can end a little past the three-quarter line; if that takes the site past its share, screens wait for the top of the hour.
  2. Quartz cannot foresee a busy hour that had no busy hour at the same time of day in the last seven days (a site's first working day, say), so background work started early in such an hour can leave screens waiting later in it.
  3. 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; beyond their allowance, their checks then wait for the top of the hour.
  4. An account in about 200 Jira 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, and busy people in many groups can then reach that limit later in the hour.
  5. 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 (see Limits Quartz sets); Jira admins are not affected.
  6. The hourly or daily check can be delayed by hours while Quartz catches up with a large backlog of changes on requests, because that catching up goes first in every hour.
  7. When Quartz reads the members of a large Jira group in parts over more than one hour, a person who leaves the group between two parts is missed until the next hourly re-check.

Measured on a test site: a heavy hour of one admin (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. A first read of 3,000 requests, a bulk edit of 500 and a bulk move together reached the share within one hour; Quartz then held its background checks until the next hour, and Jira refused nothing.

An import or a restore does not start while Quartz cannot read Jira for the rest of the hour, for any of the three reasons above: the card says why and until when, and that nothing has changed. A comparison started meanwhile 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. See Backups and the configuration file.

Limits from Jira and the platform

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.
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 Reports and Compliance say from which month: "Row detail and medians cover March 2026 onwards on this site; counts and rates cover the whole history." Configuration health warns before that happens. 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. The rollup starts only when the database measures 90 percent full, never from a projection, and stops once it is under 80 percent (see How long Quartz keeps its records).
4. The first read of a large site's history takes time (above). Every page shows how far it got.
5. Jira limits how much every app may read and write each hour, in points (above). 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. The share covers everything but changes on requests, so on very busy sites history, checks, reports and field values can lag, and pages say why and until when, as above. History, background checks and reports stop for the hour at three quarters of the share, less what changes on requests and permission checks are expected to need in the rest of the hour, so the rest stays for them and for screens, and permission checks have limits of their own (above). A site where many people work in Quartz at once needs a per-site pool, which also removes what the shared pool cannot rule out (above). 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.
9. Jira's user search returns no total, so people pickers say "Showing the first 50".
10. For a site that ran Quartz before Quartz 5, Forge did not record who installed it. Getting started then names nobody, and when Forge cannot give the install date either, it 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 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 page that only reads may use Jira's last answer for that long (whether the person is a Jira admin for 30 seconds, their groups for 10 minutes); a refusal is always checked with Jira again first, so a right given in Jira works at once. A change on Quartz's Permissions page applies at once. Which Jira fields a person can see is read the same way 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, so a field Jira hides from them, or gives them, shows in Quartz within 10 minutes. A save always asks Jira at that moment about the fields it names. A Jira admin sees every field, so for them Quartz 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 (see Reports). A scheduled run of a saved view is kept in Report history.
17. Long background work continues where it stopped. The platform allows 1,000 background steps from one start; Quartz's long jobs continue 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. See SLA Fields.
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. Large configurations. 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, 1,000 calendars, 1,000 holiday schemes, 1,000 working-time schemes, 2,000 SLA fields and 1,000 alert rules, far more than the largest configuration measured; the table below has the sizes.

Limits Quartz sets

These sit far above everyday use. Each answers with one plain sentence when reached.

How long Quartz keeps its records

You set how long Quartz keeps SLA timer history, alerts, the audit log and backups in Settings > How long Quartz keeps its records. Report history and extension and exception records follow those settings, and the other times below are fixed. Quartz says what a shorter choice would remove before you save, and each change is in the Audit log. Removing a record cannot be undone.

Audit entries and extension records leave at the next hourly clean-up after they pass their time; history and alerts at the next daily clean-up (02:30 in your site's time zone). A backup leaves the Backups page once it passes its time, and Quartz frees its storage at its next backup clean-up, which runs once a day. The other records of Quartz's key-value storage that leave after a time expire at that time, and Atlassian's storage deletes an expired record up to 48 hours later.

When the database nears its limit, Quartz rolls the oldest months of row detail into daily counts, month by month and SLA by SLA. A daily count is kept per SLA, project, priority, work type, request type, assignee's account id, calendar and goal tier; daily counts follow the SLA timer history setting, and a request deleted in Jira does not remove them. Counts and rates stay exact for the whole history, also "for as long as the request exists"; medians, percentiles, row drills and CSV rows cover the detail months, and Reports and Compliance say from which month. Configuration health tells people who configure Quartz before a rollup happens. Quartz measures its database once a day against this site's allowance (1 GiB on a production site). The rollup starts only when the measured size reaches 90 percent, never from a projection; it takes the oldest months first until the database is under 80 percent, records an entry in the Audit log ("Turned old SLA timer history into daily counts"), and leaves a note in configuration health. Settings also shows, once Quartz has 14 days of readings, when the database would reach 90 percent at the usual growth; that projection is for information only and never starts a rollup.

When Quartz is uninstalled, Atlassian deletes everything Quartz stores. What Quartz wrote into Jira (values in the fields you mapped, notes and replies, its search property on requests) stays in Jira.

See also Privacy and where data lives.

Something unclear or wrong on this page? Contact support.