Why JQL Time in Status Queries Doesn't Give You Real Time Data

[#1]

If you've ever typed a JQL time in status query into Jira, hoping to get duration metrics back, you've probably hit the wall every Jira admin eventually hits: JQL is brilliant at finding issues, but it was never built to calculate how long those issues sat in a status.

Try this:

status CHANGED FROM "In Progress" TO "Done" DURING ("2026/04/01", "2026/04/08")

Run it, and you'll get a list of issues that moved from "In Progress" to "Done" inside that window. 

What you won't get is the one thing you actually wanted: how long each issue stayed in "In Progress" before it got there. That's the core limitation behind every jira time in status jql workaround teams try to build. JQL search syntax can filter and surface issues, but it has no native concept of duration.

What a JQL Time in Status Query Can Actually Answer

JQL does get you partway there. With the right operators, you can:

• Find stuck issues: status = "In Progress" AND NOT status CHANGED AFTER -10d
• Surface recently completed work: status changed to "Done" after -14d

These queries move JQL from pure search into something closer to time analysis. They're useful for spotting individual issues that look stale. But they stop short of giving you a number like a: 

• Cycle time
• Lead time 
• Time in status 
• Average time in status
• Transition time

You still have to open each issue, scroll its history, and do the math by hand.

The Questions JQL Time in Status Can't Answer

Ask most Jira admins what they actually need to know, and it's rarely "which issues match this filter." It's usually:

• How long was this issue actively being worked on, not just open?
• What's the average transition time between Dev and QA?
• Where in the workflow is time being lost?
• Which issues are aging past what's normal for this team?

No clever JQL query, however well written, returns those answers directly. JQL has no built-in way to calculate cycle time, lead time, resolution time, time-in-status, or wait time. It can't detect bottlenecks or flag aging work against a threshold. It just finds issues, the math is left to you.

Why This Gap Matters

Cycle time, lead time, and time-in-status are the metrics that tell you whether a process is healthy, not whether issues exist, but how they flow. 

Why? 

• Support teams need to know if P1 tickets are breaching SLA. 
• Dev teams need to know where review or QA handoffs create drag. 
• Ops teams need aging reports that flag work before it becomes a problem.

When the only tool available is JQL, teams end up exporting issue history to spreadsheets and calculating durations manually and slowly. And it doesn't scale past a handful of issues.

How Time in Status Reports Picks Up

This is the gap that the Time in Status Reports report closes.

Instead of treating time-in-status as something you reverse-engineer from a Jira JQL query, Time in status report calculates it directly from Jira's status-change history. 

Every time an issue moves from one status to another, Time in status report records the timestamp and uses those events to calculate how long the issue spent at each stage of  status (for example, "In Review" or "Testing"). 

Time in status report calculates this automatically from status-change events and stores the result in a calculated custom field that can be queried with JQL.

• Transition Time: Tracks the time taken to move between two specific statuses, such as from "In Development" to "Code Review." This helps teams identify delays between workflow stages.

• Cycle Time: Calculates the total time work spends in active development stages, from the moment development begins until the issue reaches a completed state. 

Teams can group multiple statuses such as "In Dev," "Unit Testing," and "Code Review" into a single logical stage to reflect the true development cycle.

• Lead Time: Measures the end-to-end duration from issue creation (or another chosen starting point) until completion, providing visibility into the total delivery timeline experienced by customers or stakeholders.

Supporting capabilities that improve the accuracy of these metrics include:

1. JQL-enabled time filtering: Because calculated durations are written into custom fields, teams can create queries such as ""Time in Review" > 48h", something native Jira JQL cannot calculate on its own.
   
   
2. Custom status grouping: 

Combine multiple workflow statuses into a single reporting stage to avoid fragmented duration measurements.

1. Configurable working calendars:

Define working days and hours so weekends, holidays, and non-working periods are automatically excluded from calculations.

1. Real-time dashboard gadgets: 

View live charts and reports that update as issues move through workflows, helping teams spot bottlenecks as they emerge.

1. 20+ specialized Time in Status reports: Analyze cycle time, lead time, time in status, transition time, SLA performance, aging work, and other delivery metrics without requiring manual calculations.

Seeing It, Rather Than Calculating It

Numbers in a table tell part of the story; trends tell the rest. Time in Status Report includes visual reporting built for exactly this:

• Scatter plots that make outliers and slow-moving issues visible at a glance, instead of buried in a list.
• WIP run charts showing aging issues and overall flow health over time.
• Agile metrics gadgets for quick KPI checks on a team dashboard.

The underlying data is calculated natively in Jira rather than synced to an external system, so what you see on the chart matches what's actually in your instance.

Why Teams Choose Time in Status Report Over Broader Time-Tracking Suites

Compared to broader analytics add-ons, Time in status report stays deliberately narrow:

• Data stays in Jira: no external sync, no second copy of your issue data sitting elsewhere.
• Focused scope: solves time-in-status and workflow visibility specifically, rather than spreading across every possible Agile metric.
• 20+ dedicated report types built around the question teams actually ask: how long did this take, and where did the time go?
• Flat, transparent pricing tiers instead of per-user scaling that gets expensive as a team grows.

The Bottom Line

A JQL time in status workaround can help you locate issues that look stuck or recently moved, but it was never designed to calculate duration, flag SLA breaches, or surface bottlenecks. For that, you need a reporting layer purpose-built for the question which is exactly what Time in Status Reports by RVS Softek provides, natively, inside Jira.

Ready to stop estimating how long work takes and start measuring it?

See exactly where work slows down, identify bottlenecks before they impact delivery, and make data-driven decisions with accurate cycle time, lead time, transition time, and time-in-status metrics.

Check out the Time in Status Reports plugin and turn Jira workflow data into actionable insights.