Time in Status for Jira: Finding Where the Work Actually Waits

A ticket took nineteen days from start to done. Nobody spent nineteen days on it. Somewhere in there it sat in Code Review over a weekend, went back to In Progress for an afternoon, waited four days in Ready for QA because the tester was on another release, and spent a day and a half in a status called Blocked that the team created and then stopped looking at. The interesting number is not nineteen. It is the four days, and Jira already knows about them.

That is the useful framing for this problem. The data exists in every Jira instance, in the work item history, and the question is only how much effort to spend turning it into something readable.

What Jira already records and what it shows

Every status change is written to the work item's changelog with a timestamp. That is not a feature anyone has to enable, and it is exposed through the REST API at the changelog endpoint for an individual work item. Any number anybody ever quotes about time in status, from any app, is derived from that same history.

What Jira does not ship is a per work item table of how long each one sat in each status. The two native reports come at the question from a different direction.

The Control Chart

Jira's own documentation describes the Control Chart as showing the cycle time, or lead time, for a product, version or sprint. It takes the time spent by each work item in a particular status or set of statuses and maps it over a period, showing the average, a rolling average and the standard deviation. It lives under the Reports tab of a software space, and the statuses it counts are configurable, because only the team knows which of its statuses represent work rather than waiting.

The same documentation draws the distinction that causes most of the confusion in this area. Cycle time is the time spent working on a work item, typically from when work begins to when it is completed, and it includes any later rework if the item is reopened. Lead time runs from when the work item was logged, not when work began, until it is completed. A team quoting one and a stakeholder hearing the other is a routine source of disagreement.

The Control Chart is genuinely useful for the question of whether the process is stable, which is what a control chart is for. A tight spread means recent history predicts future performance. A wide spread means it does not, and no average is worth quoting. What it will not tell you is which status is absorbing the time, because it aggregates the statuses you selected into a single duration per item.

The cumulative flow diagram

The other native report, also under Reports, shows the quantity of work in each status over time as stacked bands. A band that gets steadily thicker is a queue forming, and that is often enough to identify the bottleneck without any additional tooling. It answers where work is piling up rather than how long each item waited, which for the purpose of fixing a process is frequently the more actionable of the two.

For a lot of teams, those two reports plus an honest look at the board are sufficient, and the right decision is to stop here.

Time in status is not one number

Before choosing a tool it is worth knowing that the same work item legitimately has several different durations depending on decisions nobody writes down.

Calendar time or working time. An item that entered Code Review on Friday afternoon and left on Monday morning waited three days by the clock and a couple of hours by the working calendar. Both are true. Calendar time is what a customer experiences and working time is what the team can influence. Reporting one while discussing the other produces arguments that look like disputes about data.

Repeat visits. If an item enters In Progress three times, time in status is usually the sum, which is right for effort and wrong for answering how long the first attempt took. Any tool that reports a single figure has made this choice for you.

Statuses that overlap. Teams often use a flag or a label for blocked rather than a status, so blocked time is hidden inside whatever status the item was already in. That time does not disappear from the total, it just becomes invisible to the breakdown, which is the most common reason a report shows a long In Progress duration that nobody recognises.

Where the measurement starts. Time in the backlog is usually not the team's problem and usually dwarfs everything else. Almost every credible measurement excludes it, which means the first configuration decision is which status counts as the beginning.

None of these are tool problems. They are definition problems, and a team that settles them on a whiteboard first will get value from whatever it installs. A team that installs first will spend a month arguing about whose report is right.

Four ways to get the number

Route	Effort	What it gives	Limits
Control Chart	None, already there	Cycle and lead time distribution, rolling average, standard deviation	Aggregated per item, not broken out by status
Changelog via API or CSV export	A day of scripting, then it is free	Exactly the definition you choose, in a spreadsheet or a warehouse	Somebody has to maintain it, and nobody does after that person leaves
Marketplace app	An afternoon	Per status durations per item, custom fields, dashboard gadgets, working calendars	An annual bill that scales with user count, plus a third party holding your data
A tool that exposes it without an add on	A migration	Status durations as part of the base product	Only relevant if changing tools is already under consideration

The second row deserves more credit than it usually gets. Pulling the changelog for a few hundred work items and computing durations is a small script, and it has the advantage that the definitions are explicit and arguable rather than buried in somebody's product. The reason it is not the standard answer is maintenance, not difficulty.

What the apps cost, checked today

Prices below were read from the Atlassian Marketplace on 27 September 2026, in US dollars, for Jira Cloud on an annual subscription.

Users	Time in Status by SaaSJet	Timepiece by OBSS
Up to 10	Free	Free
15	$172.50 per year	$180 per year
25	$287.50 per year	$300 per year
50	$575 per year	$600 per year
100	$1,150 per year	$1,200 per year

Two observations. The first is that both are free up to ten users, which is the same threshold as Jira's own Free plan, so a team of ten or fewer can have per status reporting at no cost at all. That is worth knowing before anyone builds a spreadsheet.

The second is that the two leading apps are within a few per cent of each other at every tier, which means price is not the deciding factor. The choice comes down to whether the reports match the questions the team asks, and both offer trials. For scale, an app for fifty users at $575 a year is roughly the cost of six user months of Jira Standard, which is listed at $7.91 per user per month, so this is a small line item rather than a project.

The decisions that matter more than the tool

Once a report exists, three configuration choices determine whether anybody trusts it.

Set a working calendar and say so. Most apps support business hours and holidays. Pick one convention, write it at the top of the report, and never mix the two in the same conversation. A queue measured in calendar days and a queue measured in working hours are different metrics with the same name.

Group statuses into working and waiting. The single most useful transformation of this data is not a per status list. It is the ratio of time spent being worked on to time spent waiting. Teams that run this for the first time are commonly surprised by how small the working fraction is, and that ratio is a better argument for changing the process than any individual status duration.

Turn blocked into a status or accept that it is invisible. If blocking is recorded as a flag, no status based report can see it. Either make it a status, with the cost that the board gets a column nobody likes, or add a field for reason and duration, or accept the gap and stop being surprised by it.

What to do with the number

The point of the measurement is to change something, and there are only a few moves that follow from it.

If one status holds a long queue, the constraint is downstream capacity, and the usual answer is a work in progress limit on the column before it rather than pressure on the people in it. If Code Review is the queue, reviewing becomes somebody's first task of the day rather than their last. If Ready for QA is the queue, the handoff itself is the problem and the fix is usually to stop having one.

If the variation is large rather than the average being high, the problem is intake rather than throughput. Items are arriving in wildly different sizes or in unclear states, and a definition of ready does more than any process change downstream.

One caution about how the number gets used. Time in status measures the process, not the people. A dashboard of per person durations reliably produces items being moved to done before they are done, which destroys the data and the trust at the same time. The teams that get value from this keep it at the level of the column, not the assignee.

It is also worth asking whether the reporting needs to be reconstructed at all. Some tools expose how long an item sat in each column as part of the base product rather than as a paid add on, and a team already weighing a change of tools can fold this into that decision rather than treating it as a separate purchase. Checking what a candidate includes by default and what it charges for the people who only read reports is the fast version of that comparison, and side by side comparisons cover where the boundaries usually fall.

What to change first

Open the Control Chart for the last two sprints and look at the spread rather than the average, then decide whether a per status breakdown would actually change a decision. If the team is ten people or fewer, install one of the free apps this afternoon and settle the working hours question before reading a single number. If a tool change is already on the table, a product where status durations are part of the base package, such as Pinateca, removes the add on entirely.

Q1. Can time in status be seen in Jira without installing an app?

Partly. The Control Chart under the Reports tab gives cycle and lead time across the statuses you select, and the cumulative flow diagram shows where work is accumulating. Neither produces a per status duration per work item. For that, the options are a marketplace app or a script against the changelog endpoint in the REST API, which holds every status transition with a timestamp.

Q2. What is the difference between cycle time and lead time in Jira?

Atlassian's documentation defines cycle time as the time spent working on a work item, typically from when work begins until it is completed, including any extra work if the item is reopened. Lead time runs from when the work item was logged rather than when work started. Lead time is therefore always the longer of the two, and it is closer to what a requester experiences.

Q3. Do the time in status apps cost anything for a small team?

Both of the leading apps are free for up to ten users on Jira Cloud, the same threshold as Jira's own Free plan. Above that they are priced per user tier on an annual subscription, starting around $172 to $180 a year for up to fifteen users and reaching roughly $1,150 to $1,200 a year for a hundred.

Q4. Why does the report show a status duration nobody recognises?

Usually because blocked time is hidden. If the team marks blocking with a flag or a label rather than a status, that waiting is counted inside whatever status the item was already in, which inflates In Progress. The other common cause is a calendar mismatch, where the report counts weekends while the team is discussing working hours.

Q5. Should time in status be used to measure individual performance?

It is a poor measure of people and a good measure of process. Per person dashboards tend to produce items being transitioned early to make the numbers look better, which corrupts the only data source there is. Keeping the analysis at the level of the column, and acting on queues rather than on individuals, is what makes the measurement survive past the first quarter.