Privacy Policy — Status Clock: Time in Status & SLA for Jira

Effective: 6 September 2026

Status Clock ("the app") is published by Two Little Moons Consulting (ABN 49 732 400 198), based in Penrith, NSW, Australia ("we", "us"), on the Atlassian Marketplace. This policy explains exactly what the app does with data.

Where the app runs

The app is built on Atlassian Forge and runs entirely on Atlassian's own infrastructure, inside your site's installation. Its manifest declares no external fetch permission of any kind — there is no server of ours for data to reach, and no third party receives anything. We have no analytics, no error-reporting service and no sub-processors.

We cannot read your Jira data. Nothing in the app sends it anywhere, and we have no access to your installation's storage.

Data the app reads from Jira

Always on your behalf and with your own Jira permissions, never with elevated rights, except where noted under "Data the app writes" below:

Issues matching the query you run: key, summary, project, issue type, priority, status, assignee, reporter, parent, labels, components, fix versions, resolution, creation and resolution dates, and sprint membership.
Each issue's changelog — the history of what changed and when. This is the raw material for every duration the app reports.
The site's status catalogue, field catalogue and project list.
Sprint names and dates, for reports that measure time in a sprint.
Your own Atlassian account id, timezone and Jira group memberships, to identify you and to apply the access rules an administrator configured.
Whether you may administer Jira, to decide whether you may change settings.
Display names of people appearing in a report you are entitled to read.

An issue you cannot open in Jira can never appear in a report you run. Every read is performed as you.

Data the app writes to Jira

Three things, and only these. They are written with the app's own authority because they happen in the background, when nobody is present to act on behalf of.

One issue property (tis-standing) on issues covered by an SLA, holding that issue's SLA standing: a state (met, breached, at-risk, running, paused), a breach count, a count of clocks still running, minutes remaining, a due date, and the issue's age in its current status, cycle time and lead time in hours. It holds no issue content. It exists so that ordinary Jira search can find breached issues. It creates no custom field and appears on no screen. It is written only when the value has actually changed.
A label, only if an administrator has named one, added once when an SLA moves into breach — never on every re-check. It exists to give Jira Automation a native trigger.
A comment, only when that label is added, naming the SLAs that breached.

The app never creates, transitions or deletes an issue, never edits any other field, and never sends a Jira notification of its own.

Data the app stores in Forge storage

All of the following is held in Atlassian's own Forge storage, inside your site's installation. None of it is issue content.

What	Why	Keyed by
Site settings: working calendars (including your holiday dates), status phases, tracked transitions, teams, SLA definitions, access rules, and the integration switches	So everyone in your site sees the same configuration	One record per installation
Saved views: a name, and the report configuration — a JQL query, a date window, a grouping, a chart choice	So you do not have to rebuild a report you use every week	The account id of the person who saved it
The last SLA standing published for an issue: the same handful of numbers as the issue property	So a repeated Jira event can be recognised and skipped instead of rewriting the same value	Jira issue id

Teams hold the Atlassian account ids of the people you put in them. Access rules hold Jira group names and project keys. Saved views hold whatever JQL their author typed, which may name projects and people.

A saved view stores a question, never an answer. Opening one re-runs it as you, so two people opening the same view see different issues if they have different Jira permissions. A view shared with everybody has its query readable by everybody who can use the app — exactly as a shared Jira filter does — which is why only a Jira administrator can publish one.

Storage is per installation. No data is shared between sites.

Data we collect about you

None. We operate no server, no analytics and no telemetry. We do not know how many reports you run, what you search for, or who uses the app.

Atlassian, as the platform operator, holds the licensing and billing relationship and its own logs; see Atlassian's privacy policy. The app's own runtime logs are held by Atlassian for a short period and are readable by us in the Forge developer console. The app deliberately writes almost nothing to them: three log statements exist, and they record only an error's type and message and two integers. Nothing in the app ever puts a Jira response body, a JQL query, a project key, an account id or an email address into a log.

Retention and deletion

Everything the app stores lives in your site's installation. Uninstalling the app removes it, under Atlassian's own data-retention timelines for Forge storage. Issue properties written by the app are removed by Atlassian when the app is uninstalled.

You can also clear the app's configuration at any time from the settings page, and export it as text beforehand.

Data residency

The app stores data only in Forge storage and processes it only in Forge functions, so it follows Atlassian's own data-residency arrangements for your site. Nothing is held anywhere else.

Security

No external network egress is declared or possible.
All reads run with the reader's own Jira permissions.
Configuration can only be changed by a Jira administrator, enforced on the server and not merely hidden in the interface.
Every value that reaches Jira or a storage key is validated against a narrow pattern first, and exported CSV is hardened against spreadsheet formula injection.

Contact

Questions, or a request about data: support@twolittlemoons.com. Support: https://ethanj2k.github.io/support.html

Changes

We will update this page if the app's data handling changes, and the effective date above will change with it.