Last updated: 2026-10-14
Quartz is a Jira Cloud app built on Atlassian Forge. It reads your Jira requests, their history and their comments to measure SLA timers, and reads basic user display details to show who requests are assigned to. Since Quartz 5 it also keeps a record of the SLA timers on your site: when each SLA timer started, paused and stopped, and facts of its request such as its status, its priority and the account ids of its assignee, its reporter and the authors of its comments, but not its summary, its description or the text of a comment. Some request text is kept as well, as this policy describes: a report keeps the values of the Jira fields someone adds to it, which can include a text field such as the summary, and the runs of a scheduled report keep a copy of them; for a short time Quartz also keeps a request it has just read, its summary and the words of its changes included, and the files it prepares, such as the Compliance evidence pack. Everything Quartz stores lives in Atlassian-hosted Forge storage inside your own Atlassian environment. There is no Quartz server and no external backend: Quartz sends your request data to no server outside Atlassian's cloud. Report exports are built in your browser; a few files, such as the evidence pack, are written by Quartz inside Atlassian and saved through your browser. The AI features run on Atlassian-hosted Claude, so even prompts stay inside Atlassian. The only thing Quartz sends outside Atlassian is product-usage analytics (which features are used, never your request data), sent to an analytics product on Atlassian's pre-approved allowlist; your Atlassian administrator can turn it off, and because it carries no end-user data, Atlassian lets Quartz keep its Runs on Atlassian badge. Our sub-processors are Atlassian and an analytics product on Atlassian's pre-approved allowlist. We do not sell or rent your data, and Atlassian removes what Quartz holds in its own storage when you uninstall it.
Quartz is an SLA tracking app for Jira Cloud, published by Plugin Developers ("we", "us", "our"). This Privacy Policy explains what data the Quartz app accesses and processes, why, where it is stored, and the choices you have. It applies to the Quartz Atlassian Forge app installed from the Atlassian Marketplace. This version describes Quartz 5 and its later updates.
Quartz works on any Jira project, in Jira and in Jira Service Management alike. In data-protection terms, the Atlassian customer who installs Quartz is the controller of the Jira data involved; Plugin Developers, through the Quartz app, processes that data on the customer's behalf to provide SLA tracking.
Quartz is a Forge app. That means its code runs inside Atlassian's own Forge platform, and all of its storage is Atlassian-hosted Forge storage within your Atlassian environment. We do not operate a separate Quartz server, database or cloud service that your data is sent to. This shapes everything below.
Since Quartz 5, Quartz keeps a record of the SLA timers on your site, in a database that Atlassian hosts for the app (Forge SQL) inside the same Atlassian environment. When Quartz is installed, or a site updates to Quartz 5, it reads the history of the requests your SLAs measure once, open requests first, then the finished ones as far back as the history you keep; from then on Jira's own events bring each change on a request into the record, so Radar, Reports, Forecast, the SLA fields and the alerts all count the same SLA timers. The record holds times and facts of each request, such as its status and the account ids of its assignee, its reporter and its comments' authors, but not its summary, its description or the text of a comment, and you choose how long it is kept (see Data retention and deletion).
Quartz accesses only the data it needs to measure and report on service levels:
To measure SLA timers, Quartz reads request fields (such as status, priority, work type, request type, project, dates, resolution, assignee, reporter, labels, components, Organizations and security level, and any field an SLA names or someone adds to a report) and each request's history and comments. This is what lets Quartz determine when an SLA timer should start, pause, stop or reset, exclude non-working hours via your business calendars, and decide whether a goal is on track, at risk, critical, breached or met. Forecast (Advanced edition) also scores every open SLA timer against your own resolved history, to flag the ones likely to breach. On Jira Service Management projects Quartz also reads service projects, request types and portal groups, for SLA scopes, the customer portal and replies to customers.
Quartz reads basic user profile details, such as display name and time zone, so it can show who a request is assigned to, attribute audit-log entries to a person, show times in a person's own time zone when they ask, and present readable names instead of internal account ids in Reports, Radar and on the request panel. It also reads people's groups, the members of Jira groups an SLA names, and which people are agents of a service project, to apply the grants you set in Quartz's Permissions and the rules of an SLA (for example a comment "by an agent"). To check who may browse a project, it reads the project's lead, the people and groups in its roles and the Browse grants of its permission scheme.
Quartz stores the settings you configure: SLA definitions, business-hours calendars, holiday and working-time schemes, alert rules, permission grants, app settings, saved report views and their schedules, SLA-field mappings, backups of your configuration, and the audit log of changes. It keeps each extension and exception as a record of its own, with the reason a person gave when they gave one. It also caches some computed results so that unchanged data is not recomputed unnecessarily, and for a short time it keeps some of what it reads from requests: when the request panel, the customer portal, Explain in plain words or the Rovo agent reads a request itself, Quartz keeps that read so that a repeat within seconds does not ask Jira again. That read holds the request's facts with its summary, and its history with the words before and after each change (an edited summary or description included), but not the text of a comment. The files and large reports Quartz prepares in the background are kept in parts for a short time too; the CSV files that Compliance and Governance export hold the summary of each request the person exporting may browse. All of this is stored in Atlassian-hosted Forge storage, for the times given in Data retention and deletion.
This record is new in Quartz 5. For every request an SLA measures, Quartz's database holds its id and key, project, work type, request type, priority, status and security level, when it was created, resolved and last changed, and the account ids of its assignee and reporter. A request's labels, Organizations and components are recorded only where an SLA uses them (in its scope, a goal tier or a calendar rule). For every SLA timer it holds when the SLA timer started, paused, stopped and is due, its goal, its working minutes, any extension or exception, and its outcome, and for every request the working time it spent in each status. For each comment Jira reports as added or edited on a request in a project an SLA measures (an SLA that names no project measures every project), whether or not any SLA reads comments, it holds the comment's id, when it was made, whether it was public or internal and its author's account id. For a request whose SLA reads comments it holds the same for each earlier comment as well and, where a comment condition asks, whether the author is an agent. These rows never hold a request's summary, its description or the text of a comment.
In the same database Quartz also keeps: the alerts it sent or Jira refused (for each, the request, the SLA, when, and for an email the people or groups it was for); the runs of scheduled reports (Report history), each with its figures (with the display names of the people they are grouped by, where a report groups by person), the rows it read (a request's key and facts, its assignee's account id and its SLA figures), 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) and, for a run someone started by hand, their account id; on the Advanced edition, Forecast's scores of the open SLA timers for each person who opens Forecast; a searchable copy of the audit log and of the extension and exception records; for about ten minutes, or until a report or export already running ends, which projects and requests a person may browse; and counts of how much of Jira's hourly limit for apps and of the database's time Quartz used. When someone adds a Jira field to a report as a column, a grouping or a filter, Quartz keeps that field's values on the requests the report reads (up to 255 characters each), so the report can sort, group and filter by them; this applies to whichever field is chosen, a text field included, for as long as the request is in the record. A run of a scheduled report that has such a field also keeps its own copy of those values for the requests in its rows, and that copy stays for as long as the run is in Report history, even after the request was deleted in Jira or has left the record.
We process the data above to provide the features you installed Quartz for, and to count usage as Product analytics describes:
We do not use your Jira data for advertising, profiling unrelated to SLAs, or any purpose other than operating and improving Quartz for you.
All data Quartz persists is held in Atlassian-hosted Forge storage (the Forge key-value store and, since Quartz 5, a Forge SQL database) within your own Atlassian environment. There is no Plugin Developers server, database or third-party cloud that your request data is transmitted to: Quartz sends request data to no server outside Atlassian's cloud.
Because Quartz runs entirely on Atlassian, what Quartz stores stays under Atlassian's infrastructure controls, and where it is stored follows the data residency Atlassian offers for Forge apps.
Some of what Quartz produces is written into Jira itself, where Jira's own permissions, not Quartz, decide who can read it: the SLA values in the fields you map and in Quartz's four built-in fields; a search property on each request Quartz measures while it is open, which stays once the request is resolved and holds its SLA states, its next deadline, its minutes left, its breached count, opaque tokens and, on a request whose customer portal panel has nothing to show, the word hide, never an SLA name; the answers of Quartz's JQL function, quartzSla(); a setting that tells the customer portal where to show SLA timers; and the notes and replies your alert rules write.
When you export a report (CSV, Excel, PDF, a chart image or a calendar file), the file is generated client-side in your browser from what Quartz answered and downloaded directly to your device. Quartz's functions inside Atlassian may prepare the rows of a large export, but no web trigger is involved, so exporting does not send your data anywhere outside Atlassian and your own machine. Some files are written by Quartz inside Atlassian instead, and your browser only puts them together and saves them: Compliance's evidence pack and the Export CSV files of the Audit log and of Governance, which Quartz keeps in its storage in parts that expire after a day, and the configuration file, whose later parts Quartz keeps for an hour when the file is large. Once the configuration file or a backup is saved, Quartz's page records the download in the audit log; a download whose record could not be written is not in the audit log. Report exports, and the Export CSV files of the Audit log, Governance and Compliance, are not recorded there. Scheduled reports send a link through Jira's own notifications: the message Quartz gives Jira holds the view's name, the period, the link and the key of the request it is sent from, never the figures. Each run is kept in Report history, where every reader sees only the requests they may browse.
Quartz's AI features are available only in the Advanced edition; the Standard edition has no AI at all. These features run on Atlassian-hosted Claude via the Forge LLM service (@forge/llm), which Atlassian runs inside its own environment. As a result, prompts stay inside Atlassian: Quartz does not send them to Anthropic, OpenAI or any other third-party model provider.
The AI features are given the SLA figures, the names and settings of your configuration, the names your site uses for statuses, priorities, projects (with their keys), work types and request types, and the words a person types into them (a question for Ask Quartz, or a description for Describe your SLA), as needed to produce a summary, an explanation, an SLA draft or report filters. A summary of a report is also given the names of its three groups with the most breached SLA timers, up to 80 characters each: for a report grouped by person these are people's names (or an account id where Jira gave no name), and for a report grouped by a Jira field they are that field's values, which for a text field such as the summary is request content. Explain in plain words, on the request panel, is given the account ids of the people an SLA timer's start or pause rules name. The AI features are never given a request's description or the text of a comment. AI answers are kept in Forge storage and used for 30 days, so the same question is not processed twice; after that Atlassian's storage deletes them, which can take up to two more days. Conversations in Rovo are Atlassian's own service; Quartz's agent there answers only people with Jira product access, and only about the requests they may browse.
To understand how Quartz is used and improve it, the app sends product-usage analytics to an analytics product on Atlassian's pre-approved Runs on Atlassian allowlist: which pages, features and actions are used, marked with your site and the state of its subscription so installs can be told apart, never with a person. We never send request data, SLA values, names, email addresses, account ids, AI prompts, or any other end-user data. Your Atlassian administrator can turn it off in Atlassian Administration, in Quartz's settings under Connected apps, and Quartz keeps working normally. So that a fault cannot send a flood of events, Quartz keeps short-lived counts in its own storage inside Atlassian, which expire within two days. This analytics is the only data Quartz sends outside Atlassian, and because it carries no end-user data, Atlassian lets Quartz keep its Runs on Atlassian badge.
Quartz uses two sub-processors:
No other sub-processor or external service handles your Jira data.
We do not sell, rent or trade your personal information, including email addresses, and we do not disclose it to third parties, except as required by applicable law or regulation. Because Quartz has no external backend, the record Quartz keeps lives only in Atlassian-hosted storage within your environment, and we hold no copy of it to share. Any non-personal, aggregate information we may handle to operate the service is processed only as described in this policy.
Quartz shows what is in a request only to people who may browse it in Jira. Radar, Reports, Forecast, Compliance's records, their exports, the dashboard gadget, the runs of scheduled reports and the Rovo agent show only the requests the person looking may browse: Quartz asks Jira, as that person, which projects and requests they may browse, respects Jira's security levels, and uses that answer for at most 10 minutes, or, for a report or export already running, until it ends. 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. Counts about configuration, such as how many SLA timers are open on a calendar, are the whole site's; they carry no request content, and only people who manage that configuration see them. Governance (Advanced edition), which only Jira administrators and people granted Full configuration can open, lists the extensions and exceptions recorded on the whole site, on the page and in its CSV export. For a request its reader may not browse, it still shows Quartz's own record of the entry: the request's key, the SLA, who recorded it, when, where it was recorded from, the working time, when an exception ends and the reason they typed, and, where it happened, that an extension was recorded after the SLA timer breached. It never shows that request's summary, and it does not say whether its SLA timer was met or breached in the end. View access being open by default does not mean cross-project exposure: the screens it opens show each user only the requests they may browse.
Administrative and configuration capabilities (managing SLAs, calendars, fields, alert rules and backups, extending SLA timers and recording exceptions) are restricted by default to Jira administrators and the groups and people an admin explicitly grants, and only Jira administrators can change Quartz's Permissions. Quartz enforces grants on its own server, not by hiding buttons, and every change a person makes asks Jira at once who they are and what they may do. 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 that person may already read. A screen that only reads may use Jira's recent answer for a short while: whether a person is a Jira administrator for up to 30 seconds, and their Jira groups for up to 10 minutes, so a change to someone's Jira groups reaches Quartz's read screens within 10 minutes; a refusal is always checked with Jira again first. For a person who is not a Jira administrator, Quartz reads from Jira, as that person, which Jira fields they may see, and uses that list for up to 10 minutes in field pickers and field names; a save always asks Jira at that moment about the fields it names, and a Jira administrator is served the site's own list of fields. Permission changes are recorded in the audit log. Per-request SLA access reflects each user's own browse permissions, and the Rovo agent answers only people with Jira product access, checking the asking user's access before revealing any data. On the customer portal, Quartz shows nothing until someone turns on Show SLAs to customers in Settings. Once it is on, a customer sees only the SLA timers of the request they are viewing on the portal, for the SLAs left on in Settings' Customer portal card (an SLA is on until someone turns it off there, an SLA created later included), under the name given to it for customers or, where none was given, the SLA's own name, and nothing of an SLA's scope, conditions or calendar.
Quartz requests the minimum Atlassian Forge scopes needed to operate:
read:jira-work: read request data, history and comments to measure SLAs.write:jira-work: write Quartz's SLA values into the Jira fields you map, its search property on requests, alert notes and replies, email through Jira's notifications, a gadget you place on a dashboard, and the assignee of a request when someone selects Take on Radar.manage:jira-configuration: create a Jira field when you ask, move it to Jira's trash when you ask, read field contexts, and extend a field's context when a Jira administrator asks.read:jira-user: read basic user profile details and groups, to show assignees, resolve names and apply grants.read:servicedesk-request (new in Quartz 5): read service projects, request types and portal groups.write:app-data:jira (new in Quartz 5): write Quartz's four built-in fields, the answers of Quartz's JQL function, and the customer portal setting.storage:app: store Quartz's configuration, audit log, backups and cached results in Atlassian-hosted Forge storage.Quartz reads request data to measure SLA timers and writes back only its own SLA values, its search property and the notes and replies your alert rules ask for. One more change happens only when a person asks for it: Take on Radar assigns the request to the person who selects it, as that person, if Jira lets them assign it. Quartz never changes a request's summary, description or status, or any other field you did not map. Quartz does not ask for permission to change project screens or to list your customers.
Quartz retains your configuration for as long as the app remains installed, until you change or delete it, because that data is what the app needs to function. For an SLA, Quartz also keeps the definition it had before each change to how it measures, and a deleted SLA's last definition, each with the account id of the person who made the change, so the SLA timers measured under them can still be read; these stay until Quartz is uninstalled. When a restore puts a deleted SLA back, its last definition stays as one of that SLA's earlier definitions. The other records are kept for the times below. You set the first four in Settings > How long Quartz keeps its records; Quartz says what a shorter choice would remove before you save, and each change is recorded in the audit log. The others are kept as each item says.
membersOf(), or in an "Assignee is in group" goal tier or calendar rule): the account ids the hourly JQL re-check last read for each group, kept to compare with its next read. Each re-check replaces the list; it has no expiry and stays after an SLA stops naming the group, until Quartz is uninstalled.quartzSla() searches (never the names), expiring 30 days after Quartz last updated them; the analytics counters, expiring within two days; and how much of Jira's hourly limit and of the database's time Quartz used, your site's permission checks included, 30 days (by kind of call, 7 days).Where this list says an entry expires, Quartz sets that time on it in Atlassian's key-value storage, and Atlassian deletes the entry after it expires, which can take up to 48 hours more.
When you uninstall Quartz, Atlassian removes the app's data stored in Forge storage, its key-value store and its database, as part of the uninstall process. Your underlying Jira requests, comments and any Jira fields you mapped remain in Jira and are unaffected, since they belong to your Jira instance, not to Quartz. What Quartz wrote into Jira stays there for the same reason: the values in the fields you mapped, the notes and replies your alert rules wrote, and Quartz's search property on requests (SLA states and deadlines, never an SLA name).
Quartz inherits the security model of Atlassian's Forge platform: access is governed by Atlassian authentication and the Jira permissions described above. The audit log provides an immutable trail of configuration, permission, settings and SLA-field changes, and of the downloads of the configuration file and of backups that Quartz's page records. Extensions and exceptions are kept as records of their own, which Governance (Advanced edition) shows. All of these are recorded in Atlassian, Quartz sends them to no server outside it, and they leave after the period you choose, or when Quartz is uninstalled. 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.
This policy and our processing of personal data are governed by the laws of the European Union, including the General Data Protection Regulation (GDPR), together with the applicable local laws of the EU member state in which Plugin Developers is established.
Because Quartz runs inside your own Atlassian environment and sends your data to no server of ours, your organisation (the Atlassian customer) is the controller of the Jira data Quartz reads, while Atlassian operates the platform and storage on which the app runs. Plugin Developers does not receive or hold your request data on its own servers. Quartz's own record identifies people by their Atlassian account ids and keeps them for the times given in Data retention and deletion. Data subjects can exercise their rights, including access, rectification, erasure and restriction, through your organisation, which controls its Jira and Quartz's settings. A request deleted in Jira leaves Quartz's record of SLA timers as Data retention and deletion describes, but Quartz does not remove a person's account id from its records when that person's Atlassian account is closed: the records keep it for the times given there. A shorter choice in Settings > How long Quartz keeps its records removes it sooner from the records that setting covers, and uninstalling Quartz removes it from all of them. Plugin Developers will reasonably assist with any such request that reaches us. For any privacy question about the app, contact us using the details below. Nothing here limits mandatory rights available to you under the data-protection law of your own place of residence.
We may update this Privacy Policy from time to time to reflect changes in the app or in legal requirements. When we do, we will revise the "Last updated" date shown above. Material changes will be reflected on this page. The version of 11 August 2026 described the previous version of Quartz, which worked out SLA status on demand and kept no record of SLA timers.
If you have questions about this Privacy Policy or how Quartz handles data, contact Plugin Developers: