Menu

Roll up logged time to the epic in Jira

Checked against Atlassian’s documentation on 3 October 2026.

Your team logs time on tasks and subtasks, and the epic shows less than was logged under it. On Atlassian Community it reads “we record time on tasks but it’s not rolling all the way to Epic”, or someone has 10 weeks logged on subtasks and an epic that shows 4. This page says what Jira adds up by itself, gives the Automation rules that carry subtask time to the epic and where they stop, then what Sumline does.

What Jira does by itself

Jira adds time up one level, and no further. Atlassian put it plainly on its issue tracker, in a behaviour update of 3 June 2025: “Time estimate and time tracking currently roll-up to 1 level up based on the hierarchy. The roll-up doesn’t go beyond that.” (JRACLOUD-70150)

What that means on an epic:

  • A story includes its subtasks. With “Include subtasks” ticked on the time tracking field, a story shows its own time plus its subtasks’ (Atlassian).
  • An epic includes its stories’ own time, and nothing below them. In Atlassian’s words, “the estimate from the Epic child will get rolled up to it but nothing from the Sub-task level”. A story with 4 weeks logged whose subtasks hold another 10 adds 4 weeks to its epic, not 14.
  • Both levels are added. A parent’s own estimate and its subtasks’ are summed, so a story estimated at 8h whose subtasks add up to 8h shows 16h.
  • Plans goes further, on Premium. On Jira Premium and Enterprise, Plans rolls estimates up through every level, inside the plan; see Sumline, Plans and Σ fields.

So if your team logs time only on stories and tasks, the epic’s time tracking already shows it. The gap is time logged on subtasks.

The Automation rules

Atlassian’s documented smart values give the time of each new worklog, {{worklog.timeSpentSeconds}}, with the Work logged trigger (smart values reference). So the rules add each subtask worklog as it is logged: the first carries it to the story, the second sums the stories into the epic.

Create a number field, say Subtask hours, and add it to stories, tasks and epics. Then:

Rule 1, subtask to story

  1. Trigger: Work logged, set to run when a worklog is created.
  2. Condition: Work item fields condition → Issue Type equals Sub-task.
  3. Branch: Branch rule / related work items → Parent.
  4. Inside the branch, Edit work item → Subtask hours → {{#=}}{{issue.Subtask hours|0}} + {{worklog.timeSpentSeconds}} / 3600{{/}} (hours; divide by 60 instead for minutes).

Rule 2, story to epic

  1. Trigger: Field value changed → Subtask hours. Tick “Allow rule trigger”, so Rule 1’s edit can start it.
  2. Condition: Work item fields condition → Issue Type is one of → Story, Task, Bug.
  3. Branch: Branch rule / related work items → Parent.
  4. Inside the branch, Lookup work items with the JQL parent = {{issue.key}}.
  5. Inside the branch, Edit work item → Subtask hours → {{lookupIssues.Subtask hours.sum|0}}.

The epic’s total is then its own time tracking (itself and its stories) plus its Subtask hours field: two numbers, not one.

Where they stop:

  • Only time logged after the rules were switched on counts. Earlier worklogs need a one-off backfill.
  • An edited or deleted worklog is not taken back off, because Rule 1 only adds.
  • A moved story keeps its hours on its old epic until something else changes there, since nothing recalculates on a move.
  • Logged time only. Original and remaining estimate need rules of their own, and so does every level above the epic.
  • A lookup returns at most 100 work items (Atlassian), and every run counts toward your site’s Automation usage.

With Sumline

Sumline is our app. It adds logged time up through every level without a rule or a field:

  • Time spent from subtask to story, epic and initiative (initiatives need Jira Premium). Logged work is real at every level, so time spent is always added up, never set aside.
  • Original estimate and remaining alongside. When a story and its subtasks are both estimated, one level counts, the subtasks by default, and the value set aside is listed.
  • Remaining time on done issues is not counted by default, and the amount left out is named; an admin can change that.
  • On the issue: the Sumline panel on an epic shows the totals for all four fields, then each child’s share in a table under it.
  • Jira Service Management spaces too: requests and their subtasks roll up under each epic.
  • Computed when you look, so an edited worklog or a moved story shows on the next open or Refresh.

What it does not do: Sumline only reads, so the totals are not written to a Jira field or to the epic’s time tracking. How it treats each time field is in How the numbers are calculated.

Sumline is not on the Atlassian Marketplace yet. Get one email when it is.