Jira Average Time in Status: What the Mean Hides

A Jira average time in status is the number everyone asks for and the easiest one to quote badly. Jira stores status changes, not durations, so the average exists only once something computes it — and the moment it does, one issue stuck in review for six weeks can double it while the median barely moves. The short answer: Jira's own Average Time in Status gadget charts a calendar-day mean over the issues resolved in the window; a report that reads the changelog gives you the average, the median, the min and the max per status in business hours. This is what the mean hides, which of the four summary numbers has which job, and the question most reports never answer out loud: which issues each number covers.

Why everyone asks for one number

A table with a row per issue and a column per status answers the question precisely — and nobody reads it in a standup. What gets asked for is one number per column, small enough to fit in a sentence, stable enough to compare against last quarter. The request is reasonable. The problem is that "average" almost always means the arithmetic mean, and status durations are close to the worst possible input for a mean.

Time in a status has a hard floor at zero and no ceiling. Most issues clear a review column in hours; one waits six weeks for a security sign-off that involved a different department and two time zones. Distributions like that are skewed right, and on a right-skewed distribution the mean sits well above the typical value — it is not describing any issue you actually shipped.

Five issues pass through In Review with working times of 4h, 5h, 6h, 7h and 318h. The mean is 68 hours. The median is 6. One of those numbers describes four issues out of five; the other describes none of them.

At a more realistic scale — a filter matching 58 resolved issues over a quarter — the effect looks like this:

Remove the single 322-hour issue from In Review and the average falls from 21h 50m to about 16h 30m — a quarter of the number gone with one row. The median moves from 6h 40m to 6h 35m. A summary whose value depends that heavily on one issue is not a summary of the process; it is a summary of that issue.

Two other things in that table deserve a look before any of it goes on a slide. The Blocked average is an average of fourteen issues, not fifty-eight — quote it with its denominator or it will be read as a property of the whole quarter. And a four-minute minimum in In Review is not a fast review; it is an approval, or an automation, and it is quietly pulling the average down.

Four decisions that change the average

Before comparing your average with anyone else's — another team, a benchmark, last quarter — it is worth knowing which four decisions produced it. Different tools decide differently and produce different numbers from the same project; what is not defensible is quoting a number without knowing which decisions are inside it.

The still-open interval. An issue that entered review twelve days ago and is still there has no closing transition, so its interval either runs to "now" or gets dropped. Dropping unfinished intervals biases the average low at exactly the wrong moment — the long-running issues are precisely the ones that have not finished yet. Counting to "now" is more honest but makes the number drift upward day by day with no transitions happening at all. Time in Status counts the current interval up to the moment the report runs; if your previous tool dropped open issues, expect the averages to rise when you switch, and expect them to be more truthful.

Issues that re-enter a status. An issue that bounced between In Progress and In Review three times spent, say, three separate 2-hour visits in review. A per-status total records 6 hours; an average over visits records 2. The two conventions diverge exactly when rework is common — which is usually when someone starts asking for the number. Totals per issue are the safer default: they answer "how much review did this issue consume" rather than "how long is a review sitting". If what you actually want is the count of those visits, that is a different report — Transition Count counts how many times each status pair occurred instead of how long it lasted.

Weekends and working hours. A review requested at 18:40 on Friday and finished at 09:10 on Monday lasted about two and a half working hours, or sixty-two and a half elapsed ones. Multiply that choice across a quarter of issues and the two averages are not near each other. A work calendar — business days, working hours, time zone, holidays — is the difference between an average the team recognises and one they argue with. Whichever clock you choose, every number you compare against has to be on the same one.

The reporting window. "Average review time in Q3" still needs a definition: issues created in Q3, resolved in Q3, or merely in review at some point during Q3? Resolved-in-period is the most stable — every interval is complete — but it lags, because a slow issue lands in the quarter it finished, not the quarter it was slow in. Created-in-period reflects recent intake but is dominated by open intervals. The date filters in Time in Status apply the same preset to created, updated or resolved explicitly, which at least makes the choice visible rather than implicit.

What Jira gives you natively

Jira Cloud has an Average Time in Status dashboard gadget, and for a single number on a wall it may be enough. It plots a line: for each day in the window you configure, the average time that issues resolved that day had spent in the statuses you picked — a scope Atlassian's suggestion tracker (JRACLOUD-77733) and consistent community reports agree on. Calendar days, mean only, and nothing at all about work still open. One more thing is worth knowing before you configure it: the status picker lists every status on the instance rather than the ones in your project's workflow. The tracked bug, JRACLOUD-77503, was closed after the list was deduplicated and alphabetised, and statuses from every other project on the site are still in it.

The Control Chart in board reports takes the opposite approach: instead of one number it plots every issue's elapsed time between two columns with a rolling average and a variation band. It is board-scoped, it aggregates by column mapping rather than by status, and the rolling average is a trend line — useful for "are we getting slower", nearly impossible to quote as "our average review time is X". Teams bounce off it not because the chart is wrong but because it answers a different question than the one being asked.

The third route is the honest manual one: export the per-issue status times and compute AVERAGE, MEDIAN, MIN and MAX yourself in a spreadsheet. This works, and it forces you to make the four decisions above consciously, which is a feature. The costs are the usual ones — the arithmetic is yours to defend, the file is stale the moment it is downloaded, and next month someone repeats the exercise slightly differently. The export walkthrough covers the mechanics; exporting from Time in Status gives you the per-issue XLSX to start from.

Where the Jira average time in status is shown, and what it covers

In Time And History the average sits in three places on the Time in Status report, and they do not all cover the same issues. That is the sentence most reporting tools leave out, so it goes first:

• The table footer — Avg, Median, Min and Max, per status column and for the total — covers the issues on the page you are reading. Fifty rows by default, and the footer states which page. Issues that never entered a status are not counted for that status.
• The KPI tiles above the table — Total time in statuses, Issues tracked, Statuses, Avg time per issue — carry the caption This page, and the tooltip spells it out: calculated across the issues on this page only, not across the whole selection. (Statuses counts the status columns in the report, not issues.)
• Chart mode computes the same four tiles over the whole selection — every issue the current filters match — and the caption changes to Whole selection to say so. The charts themselves have always aggregated over the filter rather than the page.

Two properties matter more than the arithmetic. The aggregates respect the active work calendar and the selected time format, so the summary is on the same clock as every cell beneath it — not a wall-clock number floating over calendar-adjusted rows. And the per-issue rows stay visible under the summary. When the In Review average reads 21h 50m against a 6h 40m median, the issue responsible is in the same view, a scroll away — because an average you cannot decompose into the issues that produced it is an average you cannot defend in the meeting where someone asks "which issues, exactly?"

For a whole-filter file rather than a whole-filter screen, an export runs over every issue the filter matches, not the visible page — so the workbook is the wide view even when the footer you were reading was not. How the durations underneath all of this are computed — transitions paired into intervals, the implicit first interval from issue creation, statuses an issue never visited shown as - rather than zero — is the machinery described in the Time in Status report walkthrough; the summary adds a distribution view on top without changing any of it.

And one average that is not a per-status average at all. Pick two statuses on Time in Status — In Progress → Done — and Between Statuses adds a column of working time per issue, with its own average, median, min and max in the footer. Choose first exit, which ignores later loops, or last exit, which counts every one. Up to ten pairs, saved for you, and the columns travel into exports. It answers "how long from A to B" with two statuses you named rather than a metric the app named for you.

Which number to quote

Each of the four numbers has a job, and most reporting mistakes come from giving one of them another number's job.

• Median, for expectations. "Half of our issues clear review within 6h 40m" is a sentence you can say to a stakeholder and still stand behind after the next outlier. It is the number to track week over week, because it moves when the typical experience moves and stays put when one issue gets stuck.
• Max, for conversations. Every max is a story — a dependency, an absence, a decision nobody owned. One max per status per week is a short reading list, and it is where the actual process improvements hide. Averaging the outliers away is how they survive.
• Average, for totals. The mean earns its keep when you multiply it back out: average times issue count is total time consumed, and totals are what capacity discussions need. Quote it for cost, not for expectations.
• Min, for hygiene. A minimum measured in minutes usually means an automation, a self-approval, or a column being skipped — worth knowing before it flatters the average.

And when you compare, compare like with like: the same filter, the same calendar, the same window convention, the same scope, quarter against quarter. A median on working hours against last year's mean on calendar days is not a trend — it is two unrelated numbers on one chart.

Jira average time in status FAQ

How do I calculate average time in status in Jira?

Jira stores status transitions, not durations, so something has to pair each transition with the next, attribute the interval to a status, sum per issue, and average across issues. The native routes are the Average Time in Status dashboard gadget and the Control Chart; the manual route is exporting per-issue status times and using AVERAGE and MEDIAN in a spreadsheet; a Marketplace report runs the same computation against the live changelog.

Does Jira have an average time in status gadget?

Yes — Jira Cloud ships an Average Time in Status dashboard gadget that charts an average for selected statuses over a trailing window. Know its limits before relying on it: its scope is issues resolved in the window, so a growing queue of open work stays invisible; the results are calendar days with no business-hours awareness; it reports the mean only; and the status picker lists every status on the site rather than your project's workflow.

Why is my average time in status so much higher than the median?

Because status durations are right-skewed: bounded at zero below, unbounded above. A handful of stuck issues pull the mean up while the median — the middle issue — barely notices. A large gap is not a measurement error; it is the distribution telling you to go read the max values instead of the average.

Does the average cover every issue in my filter, or only the page on screen?

Both, in different places, and the report says which. The Avg/Median/Min/Max footer and the KPI tiles above the table cover the page you are reading — the tiles are captioned This page. Chart mode recomputes the tiles over the Whole selection, every issue the filter matches, and an export covers the whole selection too. Read the caption before you quote the number.

Is average cycle time the same as adding up average time in status?

Only under one convention. Means are additive, so per-status averages sum to the average total time — but only if every status average is computed over the same set of issues, counting zero for issues that never visited. Most reports, including ours, average each status over the issues that actually entered it, and under that convention the per-status averages do not sum. Time And History publishes no cycle-time metric of its own; the honest way to get a duration between two points is a Between Statuses column for the two statuses you care about.

Does average time in status include weekends?

It depends entirely on the tool's clock. Wall-clock tools count the weekend; calendar-aware tools count only configured business hours. In Time And History the active work calendar — business days, hours, time zone, holidays — drives both the per-issue durations and the summary statistics, so the average and the rows beneath it always agree on which hours counted.

Can the average be emailed to people who never open Jira?

Yes. Set the filters on the report page, then create a scheduled report: daily, weekly or monthly, at the start time and time zone you choose, with the filters frozen as you set them. The XLSX arrives as an attachment to up to ten recipients you type yourself, and every run is listed in Export History. A scheduled run collects as the schedule owner, so recipients see the owner's view of Jira.

Read one page, then the whole selection

Open Time in Status on one project and one sprint, set the work calendar, and read the footer: Avg against Median, per status. Where the two are close, quote either. Where the average is three times the median, the Max on that same row names the issue to open — and it is on screen, not in another tool. Then switch to chart mode and watch the tiles change from This page to Whole selection: the same four numbers over every issue the filter matches. Those two readings, side by side, are what a retro argument actually needs, and they take about a minute to produce.

Time in Status is one of five reports in Time And History for Jira Cloud — Assignee Time, Time to Resolution and Time in Changes are the others, all counted in business hours against your work calendar, plus Transition Count, which counts status changes rather than hours. Install it from the Atlassian Marketplace and run it on the sprint that closed last week, or read the charts and KPI tiles documentation first. Free for up to 10 users · verified 6 September 2026.