Privacy and where data lives

In one paragraph

Quartz runs on Atlassian's Forge platform: your requests are read and measured inside Atlassian, and everything Quartz stores is in Atlassian-hosted storage; where it is stored follows the data residency Atlassian offers for Forge apps. 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, in the United States; it never carries request content, SLA values, names or email addresses, and your Atlassian administrator can turn it off in Atlassian Administration, after which Quartz works exactly the same. The AI features of the Advanced edition run on Atlassian-hosted models. Our sub-processors are Atlassian and PostHog (PostHog Inc., United States), an analytics product on Atlassian's pre-approved allowlist. We do not sell or share your data. 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.

What Quartz reads from Jira, and why

What Quartz writes into Jira

• SLA field values into the Jira fields you map on SLA Fields, and the four built-in Quartz fields. Quartz asks Jira to write a mapped field past its 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. It never asks for Jira's permission to change screens.
• Quartz's search property on each request it measures while the request is open, and kept once the request is resolved, so JQL can find requests by SLA state. A request already resolved when Quartz 5 started reading your site's changes has none unless it is reopened. It holds the worst state, the next deadline, the minutes left, the breached count, opaque tokens and, on a request whose customer portal panel has nothing to show, the word hide. It never holds an SLA name, and Quartz removes it from a request it no longer measures. A search by SLA name goes through Quartz's own JQL function, which looks the name up inside Quartz.
• The answers of Quartz's JQL function, quartzSla(): for each search Jira holds, the tokens of the SLAs and state it names. No SLA name, and no request data.
• A setting for the customer portal, as an app property of Quartz in Jira: whether the Customer portal card is on and which request types it shows, so Jira shows the Service level panel only where it has something to show.
• Notes and replies from alert rules you set up, under Quartz's own name, and email through Jira's notifications.
• The assignee, when someone chooses Take on Radar: Quartz assigns the request to that person, as that person, so Jira's own permission to assign decides.
• A Jira custom field, only when you ask Quartz to create one, and its move to Jira's trash when you ask.
• A gadget on a dashboard, only when you choose Add to a dashboard.

Quartz never changes a request's summary, description or status. Apart from the four built-in Quartz fields and the assignee that Take sets, it changes no field you did not map.

What Quartz stores

• Quartz's database: 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, with a request's labels, Organizations and components where an SLA uses them; for each comment Jira reports as 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 itself never holds a summary, a description or a comment's text. Also the alerts Quartz sent, report history runs, Forecast's kept scores of open SLA timers for the people who open Forecast (Advanced edition), a searchable copy of the audit log, and the values of the Jira fields someone adds to a report as a column, a grouping or a filter (up to 255 characters each, whichever field it is, while the request is in Quartz's record; a Report history run keeps its own copy of the values in its rows for as long as the run is kept). So a request's summary is kept in this database only when someone adds the Summary field to a report; a description and a comment's text are never kept in it.
• Quartz's key-value storage: your configuration, the audit log, extension and exception records, backups, saved views, each person's unsaved drafts and choices, a configuration file sent for import (for a day), the record of each background job, such as a report, an export or a comparison, with who started it and its result (until a day after its last step, and its parts within two days; a batch of extensions or exceptions keeps its list of requests until it ends, 30 days at most, and an Undo of extensions or exceptions leaves a note that the change was undone, with who asked, for 30 days; Compliance's evidence pack and Governance's export hold the summaries of the requests they list), AI answers, Jira's recent answer about who may use Quartz (for at most 30 seconds, and a person's Jira groups for at most 10 minutes, by pages that only read), the Jira fields a person who is not a Jira admin can see (their names and types, for at most 10 minutes, and a copy for Reports' column picker for at most 5), and for each quartzSla() search Jira holds, a fingerprint of the SLA name (never the name). Also, for a short time: 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, expires after 10 minutes); 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), each expiring after a day; the names Ask Quartz reads a question against, for each person who asks (used for 5 minutes, expires after a day); and, for each person who opens Forecast (Advanced edition), the figures from your resolved history that Forecast compares with (expire a week after they were last worked out) and a note of which of them that person last checked (expires after a day). Also short-lived records Quartz keeps its own limits with: how many points of Jira's hourly limit each person's permission checks spent in the hour, and how many groups Jira last listed for them, and the other counts of each person's recent use that Quartz limits (reads of the fields they can see and checks of an SLA field's Jira field among them), all under a one-way hash of the account id, never the id, apart from when a person last ran a schedule by hand (below); how many points all reads of people's field lists spent on the site in the hour; when configuration health's Check again last read Jira and what it spent; how far Quartz's own upkeep got and when it tries again (for the search property, in Quartz's database); a note of a gadget being added to a dashboard (the saved view, its title and who added it) until Jira confirms it, expiring 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 Quartz can record it in the Audit log, expiring after a day; a note of a recount someone started from configuration health (from which date, and who started it), expiring after 30 days; the members of a Jira group the hourly JQL re-check has read so far when it reads a large group in parts, until that read ends; and how much room the records of checked access take.
• Other facts Jira gave about people, also in Quartz's key-value storage, kept with the account id itself, not a hash: the Jira groups of an assignee, or of a comment's author, when a goal tier, a calendar rule or a comment condition names a group (used for an hour, expires after a day); the account ids of the members of each Jira group your SLAs name, in an "Assignee is in group" rule or in membersOf() in a JQL (read again every hour, and Quartz keeps the last list it read with no expiry); whether a person is an agent of a service project (used for a day, expires after 7 days); the members of the groups in a service project's Service Desk Team role, when Quartz has to read its agents from that role (used for an hour, expires after 7 days); the display name of each person a report or Forecast names, and that person's Jira groups when a report groups by Jira group (used for a day, expire after 7 days); and the display name of each person your configuration names (used for 5 minutes, expires after a day).
• Small records that hold a person's account id itself, with no expiry, also in Quartz's key-value storage, until they are replaced or Quartz is uninstalled: the SLA timers a person 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.

How long Quartz keeps its records is on Limits and data retention. A record in Quartz's key-value storage that expires after a time given here can stay up to 48 hours longer, until Atlassian's storage deletes it. You set how long Quartz keeps SLA timer history, alerts, the audit log and backups in Settings.

Who sees what

• Requests are shown as the person looking may browse them. Radar, Reports, Forecast, Compliance records, drills, exports, the gadget, schedules' runs read back, and Rovo answers show only requests that person can browse in Jira, project by project, with Jira's security levels respected. Quartz checks this when a page opens and holds the answer for 10 minutes; a person who loses access stops seeing those requests within 10 minutes. A report or export already running finishes with the access its person had when it started.
• Governance (Advanced edition) shows more. Jira admins and people granted Full configuration see the extensions and exceptions recorded on the whole site, on the page and in its CSV export. For a request they cannot browse it still shows Quartz's own record of the entry: the request's key, the SLA, who recorded it, when, from where, the working time, when an exception ends, the reason typed, and whether an extension came after the SLA timer breached. It does not show that request's summary or whether its SLA timer was met or breached in the end.
• Counts about configuration (for example how many SLA timers are open on a calendar, or Compliance evidence counts) are the whole site's. They carry no request content, and only people who manage that configuration see them, and with a limited grant, only for the SLAs inside it.
• Grants are enforced by Quartz's server, not by hiding buttons. Export reports decides who may download a report as a file: Quartz checks it for the files it prepares, and the page withholds the files your browser builds from rows the person may already read. Only Jira admins can change Permissions.
• Every change asks Jira. A save, a delete, an export Quartz prepares, an import, a restore or a job a person starts 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 change on Quartz's Permissions page applies at once. A refusal is never made from a kept answer: Quartz asks Jira again first.
• A person is named and offered only the Jira fields Jira shows them. For someone who is not a Jira admin, Quartz reads Jira's own field list as that person (Jira lists a person the fields used in projects they can browse) and uses it for up to 10 minutes: in field pickers, in Reports' column picker and for the field names configuration health shows. A field Jira hides from them reads as "a field you cannot see in Jira". A save never relies on that list: it asks Jira at that moment, as the person, about each field it names, so a field Jira has hidden from someone cannot be saved by them. A Jira admin sees every field, so for them Quartz reads the site's own field list.
• A check Quartz cannot make opens nothing. Quartz limits how many permission checks one person and one site make in an hour (see Limits and data retention). When a check cannot be made, because Jira did not answer, Jira's limit was reached, or Quartz is holding back its checks for that person or for the site, the page says "Quartz could not check your permissions", with whose checks are held back and when it checks again; nothing that needs the check is opened or changed until it is made, and the person's permissions do not change.
• Quartz's Rovo agent answers only people with Jira product access. Quartz asks Jira who is asking (a yes is used for at most 30 seconds), and a customer with no Jira product access who reaches it is refused before Quartz reads anything else, in the same words a Jira user without access gets.
• Files a non-admin downloads (the configuration file, backups) leave permissions out.
• A shared report view stores its settings only, never data, and runs as whoever opens it.
• Scheduled report emails carry a link, never figures, and Jira mails only people who can browse the request the schedule names.

AI (Advanced edition)

The AI features run on Atlassian-hosted models through Forge. They are given the figures, settings and names needed for a summary, an explanation, an SLA draft or a question turned into filters: the text you type, the names your site uses for SLAs, statuses, priorities, projects, work types and request types, an SLA's start and pause conditions (with the account ids of any people they name), and for a written summary the names of the report's three groups with the most breaches, up to 80 characters each, as the report shows them (people's names when it is grouped by person, or an account id where Jira gave no name; a field's values when it is grouped by a Jira field, which for a text field such as the summary is request content). They are not given a request's description or a comment's text. An AI answer is kept and used for 30 days so the same question is not asked twice, per person wherever it reads that person's requests, and then it expires. The Standard edition has no AI at all. See Limits and data retention for the AI allowance.

Analytics

Quartz sends usage events, such as that a page was opened or an SLA was changed, marked with your site and the state of its subscription so we can tell sites apart. They never carry request content, names, email addresses, account ids or AI prompts. Your Atlassian administrator can turn this off in Atlassian Administration (Connected apps, then Quartz), and Quartz keeps working normally.

Exports

Report files (CSV, Excel, PDF, chart images, calendar files) are built in your browser from what Quartz answered. The configuration file, backups, Compliance's evidence pack and the exports of the Audit log and Governance are prepared by Quartz inside Atlassian. Each file is saved to your device. Once the configuration file or a backup is saved, Quartz's page records the download in the Audit log, with who took it and when; a download whose record could not be written is not recorded. Report exports are not recorded there, and neither are the CSV exports of the Audit log, Governance and Compliance.

Permissions Quartz asks for

Quartz does not ask to change project screens or to list your customers.

Reporting a security problem

Quartz takes part in the Atlassian Marketplace Security Bug Bounty program. Report a security problem through the program, or write to support@plugin-developers.com with Security in the subject.

The full privacy policy is updated for Quartz 5.

Something unclear or wrong on this page? Contact support.