Every team has been there. Tasks are moving, people are busy, and yet delivery is slow. A feature that was planned to take a week takes three. Nobody understands where the time actually goes.
The total duration can tell you that the work is slow, but it doesn't tell you where it slows down.
The metric that answers "where" is time in status. In this post, I'll cover what it measures, what Jira gives you out of the box, and how to calculate it with the Time in Status app for Jira, so you can see where work slows down and act on it.
What time in status actually measures
Time in status is a metrics that tracks how long work items spend in workflow statuses. Instead of a total number, it gives a breakdown. For example, the workflow of a work item may look like that:
| Status | Time spent |
|---|---|
| In Progress | 2 days |
| Waiting for Code Review | 4 days |
| Code Review | 1 day |
| Waiting for QA Review | 2 days |
| QA Review | 1 day |
Based on this, we can see that the work item spent 6 of 10 days in "waiting" status. It is also important to clarify whether the 2 days spent in "In Progress" status represent active work or include waiting time.
How to track time in status in Jira?
There are several options that allow to get time in status report in Jira.
Days in column displays a visual age indicator on cards on supported boards when enabled. It measures column time; a column can contain multiple statuses, so it is not necessarily the duration of one status.
Control Chart uses time spent in selected statuses mapped to board columns to help you inspect cycle time, variation, and outliers. You can narrow the selection to investigate part of the workflow.
Native Jira REST API. Because Jira doesn't store "Time in Status" as a single field, you must request the issue history (changelog) and calculate the durations between timestamps yourself.
- Endpoint:
GET /rest/api/3/issue/{issueIdOrKey}?expand=changelog
- Alternative (Bulk):
POST /rest/api/3/search with the body parameter "expand": ["changelog"]
How it works:
- Parse the JSON response down to the changelog.histories array.
- Filter history items where field equals "status".
Look at the created timestamp of the status transition to determine when an issue entered and left each state.
Marketplace apps like Time in Status by SaaSJet
One of the limitations of native approach is that it counts calendar time. This can make a work item’s time in status look longer than it is within your team’s working hours.
Marketplace apps such as Time in Status by SaaSJet allow to create time in status reports from the same Jira history, but let you set working calendars with business hours, time zones and holidays. This gives you status durations that reflect your team’s actual work schedule.
What to look for in the numbers
Waiting stages that dominate the journey
If “Waiting for Review” takes longer than “In Progress,” ask what controls entry into review. Is there a reviewer assigned? Does anyone pick work up from that queue? Are reviews happening in large batches?
Start with a few comparable work items. One long wait is a case to investigate; repeated long waits are a stronger reason to examine the process.
This leads to flow efficiency:
Flow efficiency = active time / (active time + waiting time) × 100%
For the illustrative table above, classifying In Progress, Code Review, and QA as active gives 4 / 10 × 100 = 40%.
Treat that as a status-based estimate. It only reflects actual active and waiting time as well as your workflow captures those distinctions.
Repeated visits that totals hide
Consider this sequence:
In Progress → In Review → In Progress → In Review → Done
The script combines both visits to each status. That gives you the total duration, but hides the back-and-forth.
To investigate possible rework, retain the transition sequence and count entries into each status alongside the durations. Did review uncover a defect? Did requirements change? Was the work item moved back for an administrative reason?
Repeated entries are a signal to investigate, not proof of poor quality. A long single visit and several short visits can produce the same total while telling very different stories.
Where the DIY approach breaks
The subtraction is easy. Making the numbers dependable for a whole team takes more work:
Working hours and calendars: business-time calculations need working intervals, holidays, time zones, and daylight-saving rules. Dividing calendar hours by eight does not remove non-working time.
Pagination: the example handles it, but every page still needs to be fetched successfully. An incomplete history produces incomplete totals.
Hundreds of work items: you need work-item discovery, rate-limit handling, retries, and consistent reporting boundaries. Work items changing during a run can also produce inconsistent snapshots.
Team dashboards: someone must maintain refreshes, filters, access, visualizations, and definitions everyone understands.
Ready-made apps such as Time in Status by SaaSJet exist for teams that need calendar-aware reports and shared dashboards.
Full disclosure: I work at SaaSJet.
Which status do your work items get stuck in the longest?
Top comments (1)
Really useful metric in Jira. Thanks for sharing