How to Build a Jira Time-in-Status Report

Time in status measures the elapsed time between workflow transitions. It can show where work waits, how much rework returns to an earlier step, and which part of a process has become unpredictable.

It does not measure how many hours a person worked. Jira time tracking records estimates and work logs; time in status records the clock between status changes. Confusing the two produces a report that looks precise and answers the wrong question.

Define the question before calculating anything

“How long did this work item spend in review?” sounds clear until the workflow becomes real.

Decide:

• Which statuses count as review.
• Whether to sum repeated visits after a work item is reopened.
• Whether the report includes work still in the current status.
• Whether elapsed time means calendar time or working time.
• Which timezone defines the boundaries of a day.
• Whether cancelled and unresolved work belongs in the same comparison.
• Whether the assignee means the current owner or the owner during each status interval.

Write these choices next to the report. Without them, two correct calculations can disagree and neither reader will know why.

Use Jira’s Control Chart for a native workflow view

Jira Software Cloud’s Control Chart shows cycle or lead time across selected workflow columns. Atlassian says the report applies to company-managed spaces. You can select the columns that represent active work, review, or another part of the workflow, then inspect the average, rolling average, variation, and individual work-item dots.

Open the company-managed Jira space, choose Reports, then Control Chart. Select the workflow columns and a time period that match the question. Use a quick filter if you need to exclude cancelled work or focus on completed items.

Atlassian’s Control Chart guide explains that reopened work can add further elapsed time and that the chart can include work still moving across the board.

The Control Chart is enough when you need a process-level view of cycle time and variation. It is less suitable when the output must contain one row per work item, one column per status, custom percentiles, a reusable SQL definition, or an assignee breakdown.

Choose the calculation rules

Calendar time or working time

Calendar time counts nights, weekends, and holidays. Working time needs a calendar, timezone, working-day definition, and holiday source. Do not label a calendar-time result “business days” because you divided hours by eight.

Calendar time is often the cleaner first report because it matches the customer or stakeholder experience of waiting. Working time is useful for an SLA or staffing question only when the calendar rules are explicit.

Reopened work

If a work item enters In Review three times, total time in review usually means the sum of all three intervals. Keep the intervals separate when you want to compare first-pass review with rework.

Averages can hide this pattern. Add a visit count or a reopened flag when repeated transitions matter.

Current work

A completed status interval has an entry timestamp and an exit timestamp. The current status has an entry timestamp but no exit yet. Decide whether to exclude it or measure from its entry time to the report time.

If current work is included, the result changes every time the report runs. Label the report timestamp and avoid mixing completed intervals with still-running intervals without a clear column or filter.

Status names or status IDs

Jira administrators can reuse a status name or rename a status. A durable calculation should join by Jira’s status identifier, then display the human-readable name. Keep a mapping if several workflows use different statuses for the same process stage.

Build a report that can be checked

A useful first table contains:

Column	Why it is present
Work item key	Lets a reader inspect the source item
Status	Names the interval being measured
Entered status	Establishes the start boundary
Left status	Establishes the end boundary, or shows that it is current
Elapsed hours or days	States the unit rather than hiding it in formatting
Visit number	Exposes reopened or repeated transitions
Current-status flag	Separates running intervals from completed ones

Check several work items by hand. Include one simple path, one reopened item, one item still in progress, and one that crosses a weekend or timezone boundary.

For an illustrative check, take DEMO-42 at 18 September 2026, 12:00 UTC. All times below are UTC and use calendar hours:

Visit	Entered	Left	Hours
First	14 Sep, 09:00	14 Sep, 15:00	6
Second	15 Sep, 10:00	15 Sep, 14:00	4
Current	18 Sep, 09:00	Not yet	3

Completed visits total 10 hours. Including the current visit gives 13 hours at the stated report time. A query returning only 3 hours has dropped earlier visits; one returning 10 hours is valid only if it explicitly excludes the current visit. This is synthetic data for checking the rule, not a customer result.

After the interval table is correct, aggregate it into the view people need:

• Total time per status and work item.
• Median and average time per status.
• A high percentile for long-tail waiting.
• Count of transitions or visits.
• Current items ordered by age in their status.

Use the median alongside the average. One abandoned item can drag an average far away from the experience of most work.

Build the same analysis in Advanced Reports

Advanced Reports’ time-in-status documentation describes a histories table populated when change-history sync is enabled. Status transitions use field_id = 'status', and seconds_in_state stores the completed interval.

The current status has a NULL duration because its clock is still running. The documented calculation uses the difference between the current time and the transition date for that row. That choice should remain visible in the query rather than being buried in chart formatting.

This workflow uses the Advanced edition’s cloud database and Database Configuration settings:

1. In Advanced, select the projects and status field, enable change-history sync in Database Configuration, and wait for the sync to complete. Include the history needed for the reporting period.
2. Start with the documented per-work-item, per-status query.
3. Check the result against a small set of Jira work items and transition timestamps.
4. Decide whether to include the still-running current status.
5. Add project, date, work-item-type, or status filters.
6. Aggregate only after the interval logic passes the manual check.
7. Turn the result into a table or chart and save it with the calculation notes.

The documentation includes patterns for a status-column pivot, averages and medians, current-status ageing, status-category cycle time, and charts. It also describes AI-assisted query and chart generation; inspect the generated SQL and chart definition just as you would a manually written report. The underlying SQL should still be reviewed before the result is used for a staffing, SLA, or performance decision.

See Advanced Reports for Jira for the product workflow. Both Standard and Advanced include Local Insights, editable SQL, AI-assisted SQL, charts, and local reports. Advanced adds the synced cloud database used here, Cloud Insights, background sync, the AI Data Explorer, and Jira dashboard gadgets. The edition comparison distinguishes AI-assisted SQL in both editions from the Advanced-only AI Data Explorer.

Treat an assignee breakdown as a process question

“By assignee” can mean at least two things:

1. Group the work item’s full status history by whoever is assigned now.
2. Attribute each status interval to the person assigned during that interval.

The first is easier but can misattribute months of history to the latest owner. The second needs assignee history aligned with status intervals. Do not present one as the other.

An assignee view can help investigate queue size, handoffs, uneven work types, missing permissions, or a team member covering a specialist role. It cannot isolate individual productivity from complexity, interruptions, dependencies, leave, review policy, or how the team assigns work.

Use team-level distributions before a league table. If names are needed for operational follow-up, show the work items behind the number and give the people involved a way to correct bad workflow data.

Common errors that make the report unreliable

• Counting only the latest visit to a repeated status.
• Treating a missing exit timestamp as zero instead of current work.
• Joining by a display name when two Jira statuses share that name.
• Calling calendar hours working hours.
• Averaging away a long tail without showing the median or percentile.
• Comparing teams that use different workflow definitions.
• Grouping all history by current assignee without saying so.
• Reading workflow delay as hours worked.

Keep the raw interval table available even if the final output is a chart. It is much easier to resolve a disputed bar when somebody can open the work item and inspect the transitions behind it.

Choose native Jira, a dedicated app, or SQL reporting

Need	Better starting point
Cycle-time trend across selected board columns	Jira Control Chart
A ready-made time-in-status report with minimal configuration	Dedicated time-in-status app
Custom interval logic, joins, percentiles, or reusable SQL	Advanced Reports or another governed analytics system
One-off investigation by a technical analyst	API/export plus a notebook or BI tool

Native Jira is the honest answer when its Control Chart answers the question. A dedicated app is sensible when the standard report is the product. SQL reporting earns its extra setup when the calculation, filters, joins, or output must be controlled and reused.

Verify the calculation before saving the chart

Pick four awkward work items and reconcile their transition history with the report. Once reopened work, current status, units, and filters behave correctly, review the Advanced Reports time-in-status workflow.

View Advanced Reports on the Atlassian Marketplace.