Skip to content

Dwell

How to measure time in status in Jira (and why the changelog isn't enough)

Jira knows exactly when every issue changed status. It just never adds it up. Here is what Jira gives you, how to compute the numbers yourself if you want to, and what to look for if you decide not to.

What is “time in status” in Jira? It is how long an issue spends in each workflow status — three days In Progress, two days In Review, and so on. Jira stores every status change in the issue's changelog but does not total them, so teams compute time in status to find where work stalls. It is related to, but not the same as, cycle time (work started to done) and lead time (created to done).

In one paragraph

Jira's changelog records each status change but never totals them. To see time in status, cycle time and lead time you either compute the intervals yourself from the REST API — fiddly, because of status renames, reopened issues and whether you count weekends — or you use an app. If you use an app, prefer one that reports median and p85 rather than averages, because averages hide the slow tail that causes the complaints; and if data residency matters to your organisation, prefer one that runs inside your own Atlassian cloud.

What Jira gives you natively

Open any issue, expand the History tab, and you will see entries like “Anna changed the status from In Progress to In Review · 12 August 2026, 14:31”. That is the changelog, and it is complete: every transition, timestamped, attributed.

What it is not is a report. Three things are missing, and no amount of clicking fixes them:

  • No totals. The events are there; the durations between them are not. You are reading raw material, not an answer.
  • No cross-issue view. The history is per issue. There is no native screen that says “across this project, issues sit in Code Review for a median of two days”.
  • No handling of the awkward cases. Issues that bounce backwards, statuses that were renamed last quarter, tickets reopened after being closed — each needs a decision, and the changelog just lists what happened.

Jira's own reports do not close the gap either: the Control Chart and Cumulative Flow Diagram show flow across a board, not how long a given status holds work, and neither exports the per-status figures teams actually want to put in a review.

The manual way, honestly described

Can I get time in status from the Jira changelog myself?

Yes, and for a one-off question it is often the right call. The shape of it:

  • Pull the changelog. Find the issues with POST /rest/api/3/search/jql — the classic startAt search is deprecated — then read each issue's history from GET /rest/api/3/issue/{key}/changelog, which is paginated. The CSV export from the issue navigator does not include status history, which surprises people.
  • Keep only status items. Each history entry has items; you want the ones where field is status, with their fromString, toString and the entry's created timestamp.
  • Build intervals. Sort by timestamp and pair them up: the issue was in status A from transition n until transition n+1. Two edge cases decide whether your numbers are right — the first interval starts at issue creation in whatever status the workflow starts in (there is no transition into it), and the last interval is still open, so it runs to “now” for anything not yet done.
  • Sum per status, then aggregate. Add the intervals per status per issue, then take the distribution across issues.

Where hand-rolled numbers usually go wrong. Weekends and nights: an issue that sat over a long weekend looks three days slower than one that did not, unless you decide to subtract non-working hours — a real decision, not a detail. Status renames: “In Review” became “Code Review” in March and your grouping silently splits in two. Reopened issues: one issue can be In Progress three separate times, and if you keep only the first or the last interval you will understate it. Zero-length transitions: bulk moves produce several transitions in the same second, which can create nonsense intervals if you do not drop them.

None of that is hard. It is just enough work that most teams do it once, get a number, and never repeat it — which is the actual failure mode, because a flow metric is only useful as a trend.

Time in status, cycle time and lead time are three different things

  • Time in status — how long an issue sat in one particular status. Diagnostic: it tells you where the time went.
  • Cycle time — from when work actually started (typically the first move into In Progress) to done. This is the number teams commit against.
  • Lead time — from creation to done, including all the time it waited in the backlog before anyone touched it. This is the number your stakeholders experience.

Lead time is almost always much larger than cycle time, and the gap between them is queue time. If your team feels fast but the business feels slow, that gap is why.

Why averages mislead, and what to use instead

Cycle-time distributions have long tails: most issues finish quickly, a few take forever. An average is dragged by those few, so it describes nothing in particular — not the typical issue, and not the worst case.

Use two numbers instead. The median (p50) is the typical issue: half finish faster, half slower. The 85th percentile (p85) is the honest promise: 85% of issues finish within it. “Usually about three days, and almost always within nine” is a statement a team can actually stand behind. An average of five days is not.

What a time-in-status app should give you

There are many on the Atlassian Marketplace and most compute the same base numbers correctly. The things worth comparing:

  • Median and p85, not just averages. If the headline number is a mean, the app is answering a less useful question.
  • Something forward-looking. Historical reports tell you what already went wrong. A list of open issues already past your p85 tells you what is about to.
  • Queue time as well as work time. Per-status totals say how long each step took; flow efficiency says how much of that was waiting.
  • A free surface. Whether an ordinary team member can answer “why has this ticket taken so long?” without a licence conversation.
  • Where it runs. Reporting apps read every issue's full history. Some run on the vendor's servers; some run inside your Atlassian cloud. Both are legitimate — check which, because it decides whether you are adding a data processor.
  • Export. The number always ends up in a slide eventually. CSV export saves the retyping.

Doing it with Dwell

Dwell is our answer to the above, and the part most people use costs nothing: open any issue, go to Apps → Time in Status, and the panel shows time in each status plus lead time for that issue. That panel is free on every issue at any team size, so the diagnostic question — “where did this ticket's three weeks actually go?” — is answered for everyone.

The licensed part is the project layer: a report over any JQL with median and p85, a weekly cycle-time trend, aging work-in-progress measured against your own p85, a cycle-time histogram, group-by assignee or type or priority, a dashboard gadget, and CSV export. Reports resolve as the viewing user, so issue-level security still applies.

Dwell carries Atlassian's Runs on Atlassian badge: it builds its index inside your own Atlassian cloud and sends nothing outside. One caveat worth stating plainly — in this version durations are wall-clock, so an issue that sat over a weekend counts those days; a per-status working-hours calendar is not shipped yet.

Comparing options? Dwell and Timepiece · Dwell and SaaSJet Time in Status.

Questions

Questions

How is time in status calculated?
By replaying the issue's changelog. Each status transition starts one interval and ends the previous one; the first interval starts at issue creation, the last runs to now for an unfinished issue. Summing the intervals per status gives time in status.
Does time in status count weekends and nights?
It depends on the tool. A wall-clock calculation counts all elapsed time, including weekends; a working-hours calculation subtracts non-working periods. Dwell's current version is wall-clock. Whichever you use, be consistent — mixing the two makes trends meaningless.
What is a good cycle time?
There is no universal number, and any tool quoting one is guessing about your context. What is meaningful is your own trend and the spread between median and p85: a widening gap means predictability is getting worse even if the typical issue is unchanged.
Can I see time in status without installing an app?
Yes — pull the changelog through the REST API and compute the intervals yourself. It works well for a one-off question and poorly as a habit, which is the reason most teams end up with an app.
What is the difference between cycle time and lead time in Jira?
Cycle time measures from when work started (usually the first transition into In Progress) to done. Lead time measures from issue creation to done, so it includes backlog waiting time. The difference between them is queue time.
Get Dwell on the Atlassian Marketplace