Jira epic on track: progress against risk

Atlassian’s side checked on 3 and 7 October 2026, the figures from our demo site on 25 October 2026.

An epic can be mostly done and still late. Two things decide it: how much of the work is finished, and what it is still waiting on. Jira shows the first as a bar on the epic and keeps the second in links on its stories, so the two are never on one page. This page says what Jira shows by itself, then reads both on one epic: its progress with Sumline, its risk with Blockline.

What Jira does by itself

Progress is a bar by count. The epic’s child work items show a % done by how many children are done. It is not a field: Atlassian declined to turn it into one you can search, export or report on (JRACLOUD-80273, “Won’t Do”, August 2024).
Time adds up one level. Atlassian’s note of 3 June 2025 on JRACLOUD-70150 says rolling up “doesn’t go beyond that”, so an epic’s hours and estimates are those of its stories, and nothing below them.
Blocked is a link, not a status. A work item is blocked when another work item blocks it through a link, and teams link the stories, so the epic has no Blocks link of its own.
Dates are not compared. A search matches the link, whether or not the blocker is finished, and says nothing about whether its date lands before the epic’s.

So the bar says how much is done, a search says what is linked, and neither says whether the epic will make its date.

Progress and risk on one epic

The example is Holiday checkout, STOR-1, an epic with three stories in the demo spaces of our demo site. Blockline judges it At risk.

Blockline is our app. So is Sumline. They read what Jira already holds, and each opens from View app actions, the hexagon under the work item’s title.

How much is done, with Sumline

Sumline’s panel on the epic STOR-1: 80h estimated, 51h logged, 29h remaining and 64% complete by time, with 0 of 3 work items done, then each of its three stories’ own figures

By time, 64%. The three stories carry 40h, 16h and 24h: 80h estimated, 51h logged, 29h remaining, and complete by time is logged ÷ (logged + remaining).
By work item count, 0%. None of the three stories is done yet, and the panel says so (0 of 3 done). The two measures answer different questions, so the panel shows both.
Each story’s hours are the table. STOR-4, Payment step, holds 36h of the 51h, with 4h remaining.

Sumline is on the Atlassian Marketplace, and its page is on lineset.dev.

What could make it late, with Blockline

Blockline’s panel on the same epic leads with its level and the reason: “Blocked by PAYC-3 via STOR-4 · lands 5 Dec · 6 days after this epic’s date”. The epic’s date is 29 Nov, from its due date. Waiting on lists the three work items its stories wait on, each with the story it comes through, its owner, status and date, and the risk it brings:

PAYC-3, Refund API: At risk. It lands 5 Dec, after the epic’s date.
DATA-2, Order events stream: Watch. It has no date.
MAPP-4, Shared address SDK: OK. It lands 5 Nov, before the epic’s date.

Reading the two together

The story with most of the hours, STOR-4, is the one waiting on PAYC-3, which lands six days after the epic’s date. So 64% done by time does not make 29 Nov safe: what is left to finish depends on another team’s date, and the At risk level says so before the date passes. The conversation to have is with the team that owns PAYC-3, about that date.

Blockline is not on the Marketplace yet: the waitlist is below, and its page on lineset.dev has it too. What each level means is in How risk is judged. For every blocked epic at once, see Find the Jira epics blocked by another team. More on the Blockline home page.