Privacy policy

• Ganttry runs on Atlassian's own infrastructure as a Forge app. It reads your Jira, works out a schedule, and stores what it worked out in Forge app storage inside your Atlassian site.
• Nothing it reads or stores is transmitted to us or to anyone else. Not to a server of ours, because we run none. Not to an analytics service, because it calls none. Not to a subprocessor, because there is no path out of the tenancy for one to sit on.
• It does hold personal data — Jira account ids, and display names, and when individual people are away. That is stated below in full rather than waved at, because an app that draws a chart of who is doing what could not honestly claim otherwise.

The first question a data protection review asks, and the one that decides what every later answer means.

• You are the controller

  The data is your employees', your projects' and your customers'. You decide what goes into Jira, who may see it, and how long you keep it. Installing Ganttry does not change any of that.

• We are a processor

  We publish software that processes that data on your instruction, which is what pressing a button in the app amounts to. We do not decide what is collected and we make no use of it of our own.

• Atlassian is the sub-processor

  They host the compute the app runs on and the storage it writes to, under your existing agreement with them. They are the only one. We engage no others, and there is nowhere in the app's architecture that a second could be added without a scope change your admin would have to approve.

Across 11 read endpoints, all of them as the signed-in user — so the app sees exactly what the person looking at the chart could already see in Jira, and nothing that their permissions do not already give them. The endpoint-by-endpoint list is on the security page. In terms of what it means:

• Issues and their scheduling fields

  Keys, summaries, issue types, statuses and status categories, start and due dates, estimates and time spent, story points, sprints, fix versions, parents and issue links. This is what a bar on a chart is.

• Who work belongs to

  The assignee of each issue: their Jira account id and their display name. Rows are grouped and labelled by them, so these appear on the chart and in every export you produce from it.

• Who work could belong to

  When the assignee menu is opened, the account ids and display names of people Jira says may be assigned work in that project. Jira's own answer, per project and per user.

• An issue's history, on request

  The changelog of an issue on the chart, when somebody asks for time in status. One issue at a time, capped, and only on a button press.

• Configuration, not content

  Field definitions, link type definitions, project and filter listings, boards and the filters behind them, and the issue types a project offers. Definitions and names, with no issue data in them.

We are not going to tell you Ganttry processes no personal data. It processes some, it is a short list, and the claim worth making is the narrow one: none of it goes anywhere. Two of the things Ganttry stores are about people rather than about work.

• visit:{scope}:{accountId}

  A Jira account id, and what that person last saw on this chart, so “what changed since you last looked” can be answered. One record per reader per chart.

• people:{scope}

  Per person: their Jira account id, their display name, the dates they are away, the days of the week they work, the hours a day they give this plan, and their allocation.

• Both are keyed by Jira's account id and never by display name, which is a privacy decision as much as a correctness one: two people on a site of any size share a name, and resolving one at write time is how somebody's absence gets recorded against a stranger.
• A person's display name is stored alongside their availability so the screen can still list somebody who has left the site. Nothing else about them is stored — no email address, no avatar, no group membership, no time zone.
• None of it is profiling, and none of it is used to measure anybody. Availability changes where that person's own bars fall and nothing else: Ganttry does not move other people's work to cover for them, and it does not report on individuals to anyone who could not already run the same query in Jira.

All of it in Forge app storage, inside your Atlassian site. This is the whole list, not a representative sample — the app keeps its keys in one file for the same reason this page prints them in one table.

• personalvisit:{scope}:{accountId}

  A Jira account id, and what that person last saw on this chart, so “what changed since you last looked” can be answered. One record per reader per chart.

• personalpeople:{scope}

  Per person: their Jira account id, their display name, the dates they are away, the days of the week they work, the hours a day they give this plan, and their allocation.

• baseline:{scope}

  A frozen copy of the plan, to measure against.

• overrides:{scope}:{scenarioId}

  The bars somebody dragged, per scenario. Ganttry's opinion about the dates, not Jira's.

• scenarios:{scope}

  The scenario names, and which one is open.

• publish:{scope}

  The last publish, kept so it can be undone. One, not a stack.

• calendar:{scope}

  The team's working days and non-working dates.

• markers:{scope}

  Dates the team wrote on the chart.

• views:{scope}

  Named ways of looking at the plan.

• columns:{scope}

  Which Jira fields the chart shows as columns.

• linkopts:{scope}

  What each arrow means — its dependency type and its lag. Jira has no field for either.

• scheduling:{scope}

  Whether Ganttry works out where the bars go, and what individual rows want.

• portfolio

  Which projects the portfolio page is showing.

• source

  Whether the chart is drawn from projects, a filter or a query.

• seen:{scope}

  Which projects a filter or query turned out to cover last time it ran. A cache, rebuilt by the next load.

Nothing here is written back to Jira. A dragged bar, a baseline and a working calendar are Ganttry's opinion about your data rather than facts about your issues, which is why they live beside your Jira instead of in it. What does reach Jira is the separate, listed, deliberate act of publishing.

Is any of it sold?

No. Not to anyone, for any purpose, ever. There is no mechanism by which it could be.

Is any of it shared with third parties?

No. Atlassian hosts it as sub-processor and nobody else receives it. No advertising network, no data broker, no partner, no affiliate.

Is there analytics or telemetry?

None. The app sends no usage events, no crash reports and no product analytics of any kind. Runs on Atlassian would permit analytics egress if no in-scope End-User Data went with it; the app does not use that allowance, and if it ever does this page will say so before the release ships.

Are logs shared?

Forge writes invocation logs, which we can read in the developer console for a site that has enabled it, and Atlassian retains them on their own schedule. We log no issue content, no field values and no personal data into them deliberately. They are not shared with anyone and not used for anything but working out why an invocation failed.

Would you hand it over if compelled?

We could not. We hold no copy. A lawful request for a customer's Jira data has to go to that customer or to Atlassian, and we would tell you one had arrived if we were permitted to.

The Marketplace Partner Agreement asks every listed app to name the countries its data is stored in. Ganttry can only name one, and it is not ours to choose.

• In Forge app storage, in the same Atlassian site as the Jira it was read from.
• Which country that is is the one your Atlassian site is in. Atlassian's data residency settings apply to Forge app storage, so if you have pinned your site to a region, the app's data is pinned with it — by Atlassian, not by a setting of ours.
• There is no second location, no backup of ours, no cache in another region and no transfer to a country you have not already chosen by choosing where your Jira lives.
• Because nothing leaves your tenancy, there is no international transfer for us to have a mechanism for. Standard Contractual Clauses, adequacy decisions and the rest of that apparatus govern transfers between parties, and there is no second party here to transfer to.

Two things are deliberately left out of a backup. The `seen` cache, because restoring it would restore a stale one; and `visit`, because “what you saw last time” is a statement about a reader, and restoring somebody else's is worse than telling them everything is new.

There is no custom retention period to set, because there is no retention: the app holds what a chart currently needs, and holds it for as long as the chart exists. We keep no copy of any of it on any schedule, because we keep no copy of any of it at all.

GDPR, the UK GDPR and the CCPA give people rights over data held about them. Because we hold none of it, almost every one of them is exercised in your own site, by you, without waiting for us.

• Access and portability

  Back up and restore, in the app, writes everything Ganttry stores for a chart to a file you keep. It is the same data an access request would produce, available without asking us.

• Erasure

  Deleting a chart's data is done in the app. Uninstalling removes all of it. A single person's availability record is removed from the people screen, and their visit record is removed with the chart's data or expires on its own.

• Rectification

  Everything stored is editable in the app by anyone who can edit the chart, because all of it is a statement about a plan rather than a record we hold about somebody.

• Who to ask

  Your own Jira administrator, first — they can do all of the above without us, and faster. We will help if something is stuck, but we cannot reach into your site to do it for you.

Under the CCPA we are a service provider, we sell nothing and share nothing, so there is no opt-out to offer you — there is nothing to opt out of.

• Ganttry is a business tool, sold to organisations, and is not directed at children. No age is collected and none is inferred.
• No special category data under GDPR Article 9 is asked for, and none is stored in any field the app writes. A person's non-working days record that they are not working, not why — there is no field for a reason and the app never asks for one.
• No payment data of any kind reaches us. Atlassian bills for the app; we never see a card.

A term is never edited in place. When one changes, the version goes up and the change is written here.

• 1.0 · 24 August 2026First published.