Privacy

Applies to: Stintwise — Cycle Time & Lead Time Chart for Jira.

Every statement on this page about the app describes what its code actually does; statements about other companies rest on their published documentation, quoted where the exact wording matters. Some claims name the automated test that enforces them. Where something is a limitation rather than a guarantee, it says so.

What the app reads

To compute how long work items take, the app reads, from your Jira site:

• the saved filter you selected, its name and the JQL it contains. It is read as you each time a chart, drill panel or export is served, because that read is also the permission check described under Who can see a chart below

• when you open the settings of a gadget with no filter chosen, and again as you type in their filter box, the names of up to 50 saved filters you can see that match what is in the box, so that you can pick one. When more than 50 match, the app also looks up the filters named exactly what you typed, which reads the names of up to 250 more. Nothing else about those filters is requested until you pick one, which is then read as the first item above describes

• the list of statuses in your site, and their categories, read as you in the gadget's settings, and as the app about once an hour, when a chart is built: a build reads it when the copy the app keeps is an hour old, and builds that start together may each read it. Jira sends each status with its description, its icon and, for a status that belongs to one project, which project; only the name, the id and the category are used

• when your chart is built, as you, the ids and keys of the work items your filter returns for you that entered one of your Done statuses during the chart's range, or were created during it and are in one of them now, up to 10,000, and, when there are more, how many there are in all, counted as you

• for each of those work items, as the app: its creation date, the status it is in now, used only for a work item with no status change, whose status then tells whether it was created in Done, and its status change history — that is, which status it moved to and when. The app asks about no other work item

• to check that you can still open what your chart lists, how many of the chart's own work items, named by their ids, you can open, counted as you. Only the numbers come back; they are compared in memory and discarded, and an answer that lets you see the chart is reused for up to five minutes (why)

• at each build, as the app, whether your site has content Jira keeps from apps (Jira's data policy): a single yes or no

• when you open the settings of a gadget that has not been configured yet, your own Jira profile's time zone, so the date range and the day boundaries default to the zone you already work in rather than to UTC. This is read only while those settings are open, it is read for the person configuring the gadget and nobody else, and the only field used is the time zone

• what Jira sends along with those reads, which the app does not ask for and cannot refuse:

  • Jira's change history records who made every change — their account id, display name, avatar, time zone and, depending on that person's Jira profile visibility settings, email address — and neither of the endpoints the app uses offers a way to leave it out.
  • A change record can also carry metadata written by the tool that made the change: the name, id, avatar and profile link of another person or system involved, free-text descriptions, and any other data that tool chose to attach.
  • When Jira does not allow the batch endpoint (see history read one work item at a time), the per-item endpoint has no filter at all, so Jira returns each work item's whole change history, including changes to fields such as the summary or the assignee.
  • The saved filter comes back with its owner — account id, display name and avatar — and with the groups, projects, roles and people it is shared with or editable by. It also carries its description, whether you and how many others have marked it a favourite, and when it was last used.
  • Your own profile comes back whole — account id, display name, avatar, locale and, depending on your profile visibility settings, email address — although only the time zone is used.

  In every case the app takes out the one thing it needs — the status changes, the filter's name and JQL, or the time zone — and discards everything else in memory as the response is read. Nothing it discards is stored, logged or sent anywhere. Of what it keeps, the status changes become the records listed below, the filter's name and the time zone are saved with the gadget's settings (also below), and the JQL is used, in memory, to tell one version of the filter from the next, and not stored by the app. The build is given only the ids and keys of your work items.

It reads nothing else. It does not request, and its Atlassian scopes do not permit, write access to anything in Jira. The one scope that writes, storage:app, reaches only the app's own storage, described below.

What the app stores

Only this:

What the app never stores

Summaries. Descriptions. Comments. Attachments. Custom field values. Assignees. Reporters. Changelog authors. Any Atlassian account id. Any name or email address of any person.

This is not a policy statement, it is a property of the code, and it is checked by an automated test on every commit: the test feeds the app work items carrying a summary, a description, a comment, an assignee display name, a reporter email address, an account id and a custom field, then asserts that none of those values appears in anything the app writes to storage or sends to analytics. The fields of every stored record are additionally allow-listed, so adding a new field to a stored record fails the build.

(The tests are packages/ports/test/privacy.test.ts, "the app stores no issue content and no user identity", which runs a build, and packages/app/test/resolvers.test.ts, "what the app stores", which runs every path that writes — a chart request, a build, a build Jira refuses, a queue that refuses the job, the drill panel and both exports — and checks every stored field and that no filter name, query or account id is kept in the app's own storage. Every other test in that file checks the fields of what it wrote, too.)

Who can see a chart

A chart is built for one person, from the work items the saved filter returns for them in Jira, searched as them, and only they are shown it. The app then reads, as itself, the creation dates and status histories of exactly those work items, and asks Jira about no other. Colleagues whose access differs each see a chart of their own; two who can open the same work items see the same numbers, unless Jira changed between their first views of the day, as when a work item is reopened. A filter that uses currentUser() or another part of JQL that Jira answers differently for each person means, for each person, what it means to them in Jira.

Before any chart, drill panel or export is served, the app makes two checks as you, using your own Jira permissions. If either fails, you are not served its data.

• That you can open the saved filter the gadget is built from.
• That you can still open every work item the chart lists. The app asks Jira, as you, how many of the chart's own work items, named by their ids, you can open. If you have lost access to any since the chart was built, it is dropped and built again from a fresh search of yours. Of the work items it counts as over the item cap, those it dropped past the 5,000 it keeps are checked the same way; search results past the first 10,000, which it counts without reading, are not.

Please read this part carefully, because these are real limitations. Jira describes the counts it gives as estimates that may miss the latest changes, so access you lost a moment ago can be noticed late, and an answer that lets you see a chart is reused for up to five minutes. Work items beyond the first 10,000 your search returns are counted, by Jira's estimate for you, and never listed. An organisation's app access rule can keep the app from some projects: work the app is not allowed to read is counted and listed by key, and if the rule also hides work from the searches the app makes for you, that work can be missing from the chart without being counted; the chart says so when Jira reports that such a rule applies.

We would rather state this plainly than imply something stronger.

Where data lives

Inside your own Atlassian cloud instance. The app runs entirely on Atlassian Forge and stores its computed numbers in Atlassian's own storage, in the region Atlassian allocates to your site. The app operates no servers, no database and no infrastructure of its own. Apart from the product events described under Analytics, nothing it computes is copied to any system the app's author controls.

How long data is kept

• Your chart is built on your first view each day, over the days before today.
• Everything the app writes for a chart expires 25 hours after it is written: the chart, the record of the build that produced it, and the key that marks it as yours. Atlassian's storage then deletes it, and its documentation says "Deletion may take up to 48 hours", so a chart is gone within 73 hours of being built. The ids and keys your search returned are deleted when the build finishes, and otherwise expire the same way.
• The site's status list is read from Jira again when a build finds it an hour old, and expires the same way: it is gone within 73 hours of the last time it was read.
• Expiry is done by Atlassian's storage itself, so it happens whether or not the site's licence is current, and whether or not the app runs again.
• The secret the per-person keys are made with is one random value for the installation, kept for as long as the app is installed.
• On uninstall, the app can no longer run, and deletion is Atlassian's. Atlassian's storage documentation states that "Forge hosted storage retains data for 28 days after uninstallation", so that a reinstalled app can have its data re-linked on request; after that it is deleted.

Analytics

The app records four product events in a PostHog project hosted in the European Union:

• that a chart was built, with the number of work items it accounts for (those it charted and excluded together) as one of four bands (under 100, 100 to 999, 1,000 to 4,999, or 5,000 or more), and whether any history was missing or read the slow way;
• that a stored chart was shown on a dashboard;
• that the exclusion ledger was opened, and for which exclusion reason or for a mark on the chart;
• that a CSV was exported, and whether the whole ledger or the list in the panel.

Each event carries a salted SHA-256 hash of your site's cloud id and nothing else that could identify anyone. That hash identifies an installation, never a person. No Atlassian account id, no name, no email address, no issue key and no project name is ever sent. Automated tests check this against what is actually sent: packages/app/test/resolvers.test.ts ("what reaches the analytics processor") runs a build and every action that sends an event, and checks each event and property against the list above and each event's text for issue keys, the filter's name and query, and the cloud id; packages/ports/test/privacy.test.ts checks the build's event for the issue content described above.

PostHog keeps events available for a year on the free plan this project uses, and for seven years on its paid plans. Its documentation (posthog.com/docs/data/events-retention) does not say they are deleted after that, and says a shorter period cannot be set. The events carry nothing that identifies a person or a work item.

Sub-processors

There are no others for the app. Support email is separate: mail to stintwise@adigium.com is delivered by Cloudflare Email Routing to a Gmail mailbox, so Cloudflare and Google handle what you choose to write there.

Support, and why it is written

Support for this app is written documentation and written correspondence only. There is no chat widget, no phone number, and no live support session — by design, not by omission. A written-only support channel is also a privacy property: nobody screen-shares your Jira instance to a stranger, and no support session ever grants a third party access to your data.

Contact

Write to stintwise@adigium.com. It is a written inbox, and it is the only support channel — see the section above for why that is deliberate. The same address will be given on the app's Atlassian Marketplace listing.

For a question about your own data — what is held, or a request to delete it — say so in the subject line. Note that the app keeps nothing that names a person: its own storage holds what is derived from work item ids, keys and creation dates, status names and status timestamps, deleted on the schedule above; each chart's key, made from its viewer's site and account with a secret, which cannot be turned back into the account and goes with the chart; and that secret, one random value per installation. The gadget's settings, including the configuring person's time zone, are kept by Jira with the gadget and go when the gadget is removed.

Changes

Material changes to this page will be noted on the app's Marketplace listing.