Time Between Statuses: Explained

[#1]

A stakeholder asks why an issue is late. "It's stuck In Review" isn't an answer, and neither is a status label from 3 weeks ago. What actually helps is a number: this issue has been in deployment for 4 days, against a 1-day average.

That number is Time Between Statuses: how long it takes an issue to move from one point in a workflow to another, such as "In Review" to "Done," or "Waiting for Customer" to "Resolved."

Jira stores every status change in an issue's history. It just doesn't turn two of those changes into a duration you can read, sort, or act on.
 

Use Cases: Where Teams Actually Need Time Between Statuses

A PM or Delivery Lead needs to answer "why is this late" with a figure, not a guess.

A Scrum Master wants retros grounded in data instead of just saying "review always feels slow."

A Support Lead or IT lead wants to separate time the team spent actually working from time spent waiting on a customer or third party, without turning the metric into a way to police individuals.

A Process Owner wants to know if a delay is a one-off outlier or a pattern worth fixing.

A status label or a trend chart doesn't answer any of these. They need a duration, attached to a specific stretch of the workflow, on a specific issue.
 

Why Jira Doesn't Calculate This on Its Own

 
JQL can confirm a transition happened. A query like

project = SUP AND status CHANGED TO "Resolved" DURING ("2026/07/01", "2026/07/31") 

returns every issue in project SUP that moved to Resolved sometime in July. It's a list of issues, not a duration. There's no column showing how long each one took to get there, and nothing to add to ORDER BY to sort that list by transition speed. You can sort by created or by resolutiondate, but not by "how long it took," because JQL has no field that represents it.

Atlassian's Own Workaround Shows Why This Is Hard

Atlassian publishes a way to calculate time spent at each stage of a workflow, and the total time on the issue, using native automation. It's worth a look, because it doubles as an honest illustration of what it takes to get any status-based duration without a dedicated report.

To track time across four support levels in one sample workflow, the setup calls for:

A start-date field, an end-date field, and a running-total field for every stage measured, plus one more field for the grand total across the whole issue.

Automation conditions that compare the changelog's "from" status against a numeric status ID, looked up manually from the workflow admin screen.

Extra arithmetic in every condition block, adding the new duration to the existing total, so a reopened issue doesn't overwrite the time it already logged at that stage.

That's for one workflow with four stages. Rename a status, add a stage, or let an issue skip one, and the fields and conditions need updating by hand. None of it applies retroactively either, since the automation only starts recording from the moment it's switched on.

This isn't a flaw in Atlassian's documentation; it's a fair picture of what native tools require to produce this number.

Tracking Time Between Statuses With One Metric Instead of a Field Per Stage

In Timepiece - Time in Status for Jira, this is a report type called Duration Between Statuses (DBS). Instead of a field pair per stage and hand-maintained status IDs, a metric has a name and 3 settings:

Start At: Where the clock starts: issue creation, one or more statuses, or a date field

Stop At: Where the clock stops: one or more statuses or a date field (required)

Paused on: Optional statuses where the clock pauses without ending the metric

Pro Tip: Instead of relying on status changes, you can set Start At and Stop At to trigger from date fields. This allows you to measure performance against actual, contractual deadlines rather than Jira workflow clicks.

 A metric named "Review Time," with Start At set to "In Review" and Stop At set to "Resolved," is calculated for every issue in the report using data Jira already has in its issue history, past issues included, with no fields to create beforehand.

If an issue can visit the same status more than once, choosing whether Start At or Stop At should count the first or the last visit sets exactly which occurrence anchors the metric, recalculated from issue history every time the report runs.

	Custom fields + automation	A time between statuses metric
Setup per workflow stage	A start field, an end field, and a running-total field	One metric: a name, a Start At, a Stop At
Workflow or status renamed	Update every condition referencing the old status ID	Update the metric's Start At / Stop At selection
Issue reopens or revisits a stage	Extra arithmetic needed in the automation rule to preserve the running total	Recalculated from issue history each time, no running-total field to maintain
Past issues	No data until the fields start being populated going forward	Calculated instantly from existing issue history
Waiting time (e.g. "Waiting for Customer")	Needs its own field and its own subtraction logic	Add the status to Paused on

9 Metrics Built From the Same Time Between Statuses Structure

Cycle Time and Lead Time tend to get all the attention, but they're only two examples of the same underlying idea. Every metric below is the same structure, a start point, a stop point, and optionally a status where the clock pauses, just applied to a different stretch of the workflow.

Metric	Start Point	End Point	What It Tells You
Cycle Time	First entry to In Progress	Entry to Done	How fast work moves once someone actually starts it
Lead Time	Issue creation	Entry to Done	How long a requester waits from request to delivery
Queue Time	Issue creation	First entry to In Progress	How long work sits before anyone picks it up
Review Time	Entry to Code Review	Exit from Code Review	Whether code review is a bottleneck
QA Time	Entry to Ready for QA	Entry to QA Passed	Whether testing capacity is keeping up with delivery
Time to Resolution	Issue creation	Entry to Resolved	Overall ticket-handling speed, often tied to SLAs
Time to First Response	Issue creation	First response, or first move out of the initial status	How quickly a request gets acknowledged, independent of how long it takes to fully resolve
Issue Age	Issue creation	Now, for issues not yet resolved	Which open issues have been sitting the longest and need attention
Blocked Time	Entry to Blocked	Exit from Blocked	How much of the total time was lost to a dependency rather than actual work

None of these need a separate way of thinking. Each one is a Start At and a Stop At applied to a different pair of points, and in Timepiece this is the same Duration Between Statuses metric structure covered above, just pointed at a different stretch of the workflow.

Turning the Metric Into an Automatic Comment

 A report only helps if someone opens it. Timepiece also has a "Timepiece: Run Report" action for Jira Automation, so a metric like Cycle Time can post itself to an issue instead of waiting to be checked. 

• Build a DBS metric named "Cycle Time," Start At "First transition to In Progress," Stop At "Last transition to Resolved," and save it as a shared parameter set.

• In Jira Automation, set the trigger to "Work item transitioned" into Resolved.

• Add a "Timepiece: Run Report" action using that parameter set, and override the filter with { "filterType": "customjql", "customJql": "key = {{issue.key}}" } so it only pulls data for the triggering issue.

• Create a variable with the smart value {{fetchedTimepieceResultList.first().get("CycleTimeMetric")}}.

• Add a "Comment on work item" action, for example: "The cycle time for this issue has been calculated as {{CycleTimeMetric}}," then turn the rule on.

 
From that point, every issue that reaches Resolved carries its own Cycle Time. No one has to open a report to find it. The same action can also update fields like Original Estimate or Due Date, or feed a duration into an automation rule as a condition. If a per-issue trigger isn't what's needed, Scheduled Reports & Alarms can run the same kind of report on a fixed schedule instead. 

Conclusion

Time Between Statuses turns "it's stuck in review" into a number you can act on. Every metric above is built from the same three settings, a Start At, a Stop At, and an optional Paused on, calculated directly from Jira's existing issue history, no custom field per stage and no automation rule to maintain just to get the number. 

To learn more about Timepiece - Time in Status for Jira, visit its Atlassian Marketplace page. 

[Mia Tamm _Simpleasyty_]

Hi @Birkan Yildiz _OBSS_ 

What I liked most here is actually the modelling decision behind the solution. It’s very tempting to create another custom field every time someone asks a new question: time in review, time waiting for a customer, time to first response, time between two specific statuses… and suddenly the configuration starts growing around the reporting rather than the workflow.

Using the same transition history to derive different metrics feels much cleaner. Cycle time, queue time, review time or time to resolution are really different questions being asked of the same underlying journey through the workflow.

That makes this much more interesting than just another timer.

Really useful explanation, Brikan, especially the comparison with the “one field per stage” approach. That part clicked immediately for me.

[Birkan Yildiz _OBSS_]

Hey @Mia Tamm _Simpleasyty_

As you pointed out, by shifting the focus to extracting these metrics directly from the transition history, we keep the instance clean, scalable, and performant. And still giving teams the flexibility to ask any time-based question they want about that underlying journey.

I’m really glad that the comparison with the “one field per stage” approach resonated with you. Thanks again for reading and taking the time to share your thoughts!