How to Build a Release Timeline in Jira — 3 Methods with Copy-Paste Examples
A release date doesn't slip in one dramatic moment — it slips in six quiet ones: QA took two extra days, staging froze late, sign-off waited on legal. A release timeline pinned to the release epic makes those slips visible while they're still cheap to fix, because every stakeholder reads the same picture of what's next and what's blocked.
Jira gives you three ways to build that picture. This guide walks through them, then gives three copy-paste Mermaid Gantt examples sized for real releases: a single version, a multi-team launch, and a launch-week sequence.
Quick answer: To build a release timeline in Jira, install Mermaid Plus Diagrams for Jira, open the Mermaid panel on your release epic, and paste Mermaid gantt syntax — dateFormat YYYY-MM-DD, one task line per phase, after dependencies between them, and milestone for the launch date. Every example below is copy-paste ready. Jira Premium's Plans feature can auto-generate a timeline, but a Mermaid Gantt shows exactly the phases you choose and edits in seconds.
Method 1 — Atlassian Plans (Native, Premium)
Jira Premium and Enterprise include Plans (formerly Advanced Roadmaps): set fix versions, link dependencies, and it generates a timeline view from your real backlog.
Good for: portfolio-level views driven by live issue data, when your plan is the backlog.
The limitations: it requires Premium (team-managed and Standard projects are out), the auto-generated view shows what the backlog implies rather than the curated phases you want stakeholders to see, and it can't be annotated — no launch-day callouts, no marketing rows, no "freeze" bands. If the release is cross-functional, the parts that don't live in Jira don't exist in the timeline.
Method 2 — Mermaid Gantt on the Release Epic (Recommended)
A Mermaid Gantt chart on the release epic is the curated source of truth: it shows the phases you decide matter, dependencies shift dates automatically when one phase moves, and editing is one line of text.
Example 1 — Single Version Timeline
The baseline every release needs. Phases with dependencies, the train date as a milestone — paste onto the fix-version issue and rename:
gantt
dateFormat YYYY-MM-DD
title Release 2.14 — October train
section Development
Feature freeze :done, feat, 2026-09-15, 5d
Code complete :active, code, after feat, 4d
section Hardening
QA regression : qa, after code, 5d
Bug fixes : fix, after qa, 3d
section Release
Staging deploy : stg, after fix, 2d
Sign-off :milestone, sig, after stg, 0d
Production rollout : prod, after sig, 1d
Launch :milestone, launch, after prod, 0d
The done and active markers double as a status board — in review meetings the timeline shows progress without a separate slide.
Example 2 — Multi-Team Launch with Parallel Tracks
Cross-team releases need each team's track visible and the coupling points obvious. subgraph separates the tracks; the shared milestone is where they meet:
gantt
dateFormat YYYY-MM-DD
title Autumn launch — 3 tracks
section Platform
API v2 endpoints :p1, 2026-09-20, 12d
Migration dry-run :p2, after p1, 3d
section Web
New checkout flow :w1, 2026-09-22, 10d
E2E against API v2 :w2, after p2 w1, 3d
section Mobile
Store submission :m1, after w2, 4d
section Launch
Go/no-go review :crit, milestone, go, after m1, 0d
Coordinated rollout :roll, after go, 2d
The crit flag colors the go/no-go review red — useful when a stakeholder asks which dates absolutely cannot move.
Example 3 — Launch-Week Sequence
Launch week is its own timeline: marketing, support, and engineering in one view, hour-granular where it matters:
gantt
dateFormat YYYY-MM-DD
axisFormat %a %d
title Launch week — 2.14
section Comms
Blog + changelog draft :c1, 2026-10-12, 2d
Customer email :c2, after c1, 1d
section Support
macros/runbook refresh :s1, 2026-10-12, 2d
On-call briefing :milestone, s2, after s1, 0d
section Engineering
Feature flags on :e1, after s2, 1d
Monitor + hotfix window:e2, after e1, 3d
axisFormat %a %d renders weekday names on the axis — small change, but launch-week reviews stop generating "wait, is that the 14th or the 15th?" questions.
Method 3 — Confluence for the Full Plan, Jira for the Timeline
When the release needs risk registers, rollback plans, and comms plans around the timeline, build the full release plan in Confluence (Mermaid Plus for Confluence renders the same gantt syntax on pages), and keep the timeline itself on the release epic where engineers live. Link both ways — the epic is the daily view, the page is the archive.
Which Method Should You Use?
| Need | Use |
|---|---|
| Portfolio view generated from live backlog | Atlassian Plans (Premium) |
| Curated release timeline stakeholders actually read | Mermaid Gantt on the release epic |
| Full release plan with risks, rollback, comms | Confluence page + epic timeline linked |
A release timeline earns its keep the first time a date slips and everyone already knows which three tasks move with it. Install Mermaid Plus Diagrams for Jira, paste Example 1 onto your current release epic, and let the dependencies do the rescheduling.
Related Guides
- Mermaid diagrams for Jira sprint workflows -- the sprint-scale counterpart: task-granular timelines and the four diagram types sprint teams use
- Create Mermaid diagrams on Jira issues -- the complete guide to diagrams on Jira issues: sequence, class, and more
- Gantt charts in Confluence -- the Confluence version with three full project-plan examples