Last updated: 2026-06-24
Quartz is a Jira Cloud app built on Atlassian Forge. It reads your Jira issue data and changelogs to compute SLA timers, and reads basic user display details to show who issues are assigned to. Everything Quartz stores lives in Atlassian-hosted Forge storage inside your own Atlassian environment. There is no Quartz server and no external backend — your issue data never leaves Atlassian's cloud. Exports are built in your browser, and the AI features run on Atlassian-hosted Claude, so even prompts stay inside Atlassian. Our only sub-processor is Atlassian. We do not sell or rent your data, and everything Quartz holds is removed when you uninstall.
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.
Quartz works on any Jira project — Jira Software, Jira Work Management and Jira Service Management. 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.
Quartz computes SLA status on demand from your Jira data whenever a value is needed. It does not keep a separate timer database of elapsed time and does not backfill or copy your issues into a store of its own. The numbers you see are recomputed from Jira data each time.
Quartz accesses only the data it needs to measure and report on service levels:
To compute SLA timers, Quartz reads issue fields (such as status, priority, issue type, project, dates and resolution) and each issue's changelog and comments. This is what lets Quartz determine when a clock should start, pause, stop or reset, exclude non-working hours via your business calendars, and decide whether a goal is on track, at risk or breached. The Breach Forecasting feature (Advanced edition) also analyses your own resolved issues to flag open issues that are likely to miss their target.
Quartz reads basic user profile details — such as display name and avatar — so it can show who an issue is assigned to, attribute audit-log entries to a person, and present readable names instead of internal account IDs in Reports, the Radar and on the issue panel.
Quartz stores the settings you configure: SLA definitions, business-hours calendars and holidays, permission assignments, app settings, saved report views, SLA-field mappings, and the audit log of changes (including mute and extend exceptions). It also caches some computed results so that unchanged data is not recomputed unnecessarily. All of this is stored in Atlassian-hosted Forge storage.
We process the data above solely to provide the features you installed Quartz for:
We do not use your Jira data for advertising, profiling unrelated to SLAs, or any purpose other than operating Quartz for you.
All data Quartz persists is held in Atlassian-hosted Forge storage (the Forge key-value and entity stores) within your own Atlassian environment. There is no Plugin Developers server, database or third-party cloud that your issue data is transmitted to. Issue data never leaves Atlassian's cloud.
Because Quartz runs entirely on Atlassian, your data inherits Atlassian's data-residency and infrastructure controls. For teams operating under frameworks such as ITIL, ISO/IEC 20000 or SOC 2, this means one less external vendor to assess for data handling.
When you export a report to CSV, the file is generated client-side in your browser from the rows already on screen and downloaded directly to your device. There is no server-side export and no web trigger involved, so exporting does not send your data anywhere outside Atlassian and your own machine.
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 executes inside the Atlassian environment. As a result, prompts never leave Atlassian and are not sent to Anthropic, OpenAI or any other third-party model provider directly by Quartz.
The AI features are given only the SLA figures and settings needed to produce a summary, explanation or draft. Prompts stay within Atlassian and are not sent to any third-party model provider. AI responses may be cached in Forge storage to avoid unnecessary repeat processing.
Our only sub-processor is Atlassian, which provides the Forge platform (compute and storage) and the Atlassian-hosted Claude service that Quartz's AI features use. Atlassian processes data under its own terms and security commitments. Quartz does not introduce any other sub-processor, analytics vendor or external service into the handling of 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, there is no separate database of your Jira data for us to share. Any non-personal, aggregate information we may handle to operate the service is processed only as described in this policy.
Quartz never exposes issues a user is not entitled to see. Every user-facing scan — the Radar, Reports, dashboard gadgets, Forecast and the Rovo agent — runs as the requesting user, so Jira itself filters results to the issues that person is allowed to browse. View access being open by default does not mean cross-project exposure: results are always scoped to each user's own visible issues.
Administrative and configuration capabilities (managing SLAs, calendars, fields, permissions, and using extend or mute) are restricted by default to Jira administrators and groups an admin explicitly grants. Permission changes are recorded in the audit log. Per-issue SLA access reflects each user's own browse permissions, and the Rovo agent enforces the asking user's access before revealing any data.
Quartz requests the minimum Atlassian Forge scopes needed to operate:
read:jira-work — read issue data and changelogs to compute SLAs.write:jira-work — write Quartz's own SLA values into the Jira fields you map.manage:jira-configuration — optionally create the Quartz custom fields used for SLA data and JQL.read:jira-user — read basic user profile details to show assignees and resolve names.storage:app — store Quartz's configuration and cached results in Atlassian-hosted Forge storage.Quartz reads issue data to compute SLA status and only ever writes back its own SLA fields; it does not modify your business content.
Quartz retains the configuration and cached data it stores in Forge storage for as long as the app remains installed, because that data is what the app needs to function. Computed SLA values are not retained as a separate record — they are recomputed on demand from Jira data, so removing a cache simply means the value is recalculated next time it is needed.
When you uninstall Quartz, the app's data stored in Forge storage is removed as part of the uninstall process. Your underlying Jira issues, comments and any Jira fields you mapped remain in Jira and are unaffected, since they belong to your Jira instance, not to Quartz.
Quartz relies on Atlassian's Forge platform for its security posture: code runs in the Forge runtime, data is held in Atlassian-hosted storage, and access is governed by Atlassian authentication and the Jira permissions described above. The audit log provides an immutable, egress-free trail of configuration, permission, settings, mute, extend and SLA-field changes, recorded in Atlassian and never sent elsewhere. Because there is no external backend, the attack surface outside Atlassian is correspondingly small.
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 does not export your data, 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 issue data on its own servers. Data subjects can exercise their rights — including access, rectification, erasure and restriction — through your organisation's own Jira, which remains the system of record; 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.
If you have questions about this Privacy Policy or how Quartz handles data, contact Plugin Developers: