Jira issues have a due date and almost never a start date. So Ganttry draws each bar backwards from the finish — and when a dependency pushes an issue past its own due date, it draws the issue late rather than squeezing the bar to fit.
Not installable yet — Atlassian has it in the queue. One message and we write to you the day it clears.
The bar language
Other tools draw both with the same rectangle, so you cannot tell which half of your plan you are trusting. Here you can read it across the room.
Square end
Somebody stated this.
Somebody stated this date: a due date the plan meets, a resolution date, or a bar you dragged.
24 – 26 AugRounded end
Ganttry worked it out.
Ganttry worked it out.
inferredSquare end lost
It no longer meets its date.
A predecessor slipped, so the finish is past the due date on the issue. That end stops being a square, because it is not that date any more.
+2dPublishing
What reaches Jira
Only what you ticked.
Nothing you move reaches Jira until you publish. The dialog arrives with the bars you dragged already ticked and the dates Ganttry inferred left clear — a suggestion should not write itself into your project.
The last publish is kept so it can be undone. One, not a stack, and at most 200 changes in a single go.
Dependencies
Dependencies win over dates.
When predecessors push an issue past its due date, Ganttry draws it late instead of compressing the bar to make the plan look survivable. The status line says how many.
What each arrow means — its dependency type and its lag — is stored here, because Jira has no field for either.
What it may touch
Every number below is pinned by a test that reads the real manifest and the real source, and fails the build when they drift. Last checked 24 August 2026.
5
Scopes
a sixth would need your admin
11
Read endpoints
two carry no issue data at all
9
Write calls
over 8 endpoints
0
Requests leave Atlassian
and none is made as the app
Said out loud
Ganttry can delete an issue.
One key per request, after a dialog naming it, checked against the projects the chart is drawn from, and made as you — so your own Delete Issues permission is what decides. There is no bulk path anywhere in the resolver.
Creating an issue and deleting one are the two writes with no undo underneath them. That is why each is one at a time from a dialog: the shape of the feature has to be the safety argument, because there is nothing else left to be it.
Uninstalling
Take the plan with you.
Uninstalling makes the app's storage unreadable immediately, and a reinstall does not bring it back. So Ganttry ships back up and restore: the baseline, every dragged bar, the working calendar, who is away and when, the saved views, the chosen columns and what each arrow means — written to a file you keep.
Two things are left out on purpose. The stale project cache, and “what you saw last time” — restoring somebody else's is worse than telling them everything is new.
The whole list — every scope with the sentence that pays for it, all 11 reads and all 9 writes — is on the security page.
Documentation
Page 1
Your first chart
I installed it. What am I looking at?
Where the bars came from, what the shape of a bar end claims about its date, and what the status line is reporting.
ReadPage 2
Publishing dates back to Jira
I dragged a bar. Why did nothing change in Jira?
A drag is this app's opinion, not an edit. What publishing writes, what it ticks for you, and how to take it back.
ReadPage 3
Scenarios and baselines
What are the grey bars behind mine?
One plan can hold several. Both a baseline and a comparison draw ghosts, and only one of them is drawn at a time.
ReadPage 4
Releases
Why did changing this date warn me?
Fix versions, drawn across the plan. The one date in the app that reaches Jira the moment you confirm it.
ReadBuilt and answered by the same people
Median first reply under two hours. Blocking bugs fixed in 48. A decision on every feature request within five days — including the ones we decline.