Why JQL Can’t Show Real Time Between Statuses — and What Teams Do Instead

[#1]

If you’ve ever tried to find out in Jira how much time an issue actually spent between statuses, you probably started with JQL — and quickly ran into its limitations.

JQL is great for searching issues by status, date, assignee, or change history. But when it comes to time in status, cycle time, lead time, or the actual time between In Progress, Review, QA, and Done, JQL does not calculate duration — it only helps you find issues where the change happened. And that is exactly the point where most teams start looking for another approach.

Why JQL Can’t Calculate Time Between Statuses in Jira

JQL can answer questions like whether a status changed, what it changed from and to, and when exactly it happened. But it does not calculate how much time passed between those transitions.

For example, this query works:

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

But it will only show a list of issues that matched the condition. It will not answer questions like:

• how long the issue was actively in progress;
• what the average transition time is between Dev and QA;
• where delays are building up in the workflow;
• which issues are aging in a status longer than expected.

What JQL Can Do — and What It Still Misses

This is why JQL often seems useful for time analysis, but in practice, it only gives part of the picture.

JQL can help you find issues

For example:

status changed to "Done" after -14d

or:

status = "In Progress" AND NOT status CHANGED AFTER -10d

These queries help you find completed or potentially “stuck” issues. But they do not show exact duration, averages, trends, or workflow distribution. And that is the main limitation of native JQL.

JQL cannot give you real flow metrics

As soon as a team wants to move from simple search to delivery flow analysis, it needs more than filters — it needs a time metrics layer on top of Jira history:

• Cycle Time
• Lead Time
• Resolution Time
• Time in Status
• Transition Time
• Wait Time
• aging work items
• outliers and bottlenecks

This is where JQL stops being enough.

Best Way to Track Time Between Statuses in Jira

Instead of trying to squeeze time metrics out of JQL, teams usually switch to a specialized tool that treats transitions between statuses as a full-fledged metric.

Time Metrics Tracker | Time Between Statuses fills exactly this gap: it helps analyze Cycle Time and Lead Time, identify bottlenecks, build visual reports, export data for deeper analysis, and configure Custom Metrics to calculate time between any statuses in your workflow.

How Time Metrics Tracker Covers the Gaps JQL Leaves Behind

1. Measure real time between any statuses

Most importantly, the app does not just help you find that a transition happened — it lets you measure the actual duration between statuses. So instead of asking, “Did Dev → QA happen?”, the team gets an answer to “How long did the Dev → QA transition actually take?”

2. Configure metrics around your workflow

When setting up a time metric, you can:

• choose the required from/to transitions;
• define a status where calculation should be paused;
• set Warning and Critical thresholds and get visual color tagging for issues that exceed the limits.

This is no longer just issue search — it becomes full operational control over the workflow.

3. Use work-schedule-based calculations

Another major difference from JQL is that the app supports Work Schedule Support , meaning it takes working hours, weekends, and holidays into account when calculating metrics. This is especially useful when the team cares not about calendar time, but about the actual working time between statuses.

4. Export data for reports and retrospectives

Time Metrics Tracker also supports exporting reports to Excel/CSV. This is convenient for stakeholder reporting, retrospectives, and additional analysis outside Jira.

Why Time Metrics Tracker Is More Useful — and More Visual

One of the biggest advantages here is not only in the calculations themselves, but in how they are presented.

Scatter Plot for trends and outliers

The Scatter Plot Gadget is a visual representation of work item duration within a specific time metric. It helps analyze performance trends, identify outliers, and evaluate workflow efficiency. So instead of a dry list of issues, you can actually see where unusually long cases appear and how the dynamics change over time.

WIP Run Chart for flow health and aging issues

The WIP Run Chart shows not only how many work items are currently in progress, but also the average WIP age. Its drill-down lets you open details for a specific day, see a breakdown by status, and review the list of the oldest items. The gadget helps control flow and identify aging issues.

For a team, this is a highly visual way to spot bottlenecks — not in a table, but directly in the movement of work through the flow.

Dashboards that make metrics visible every day

The Agile Metrics Gadget lets teams monitor key KPIs at a glance, while the Scatter Plot and Metrics Gadget together help turn a Jira dashboard into a real performance hub. This makes time metrics not a one-time report “for a manager,” but a visible and ongoing part of the team’s daily work.

Example: JQL vs Time Metrics Tracker

Imagine you want to understand how long it takes for an issue to move from Submitted to Approved.

JQL can help you find the issues themselves:

project = BANKING AND issuetype = "Loan Request"

But it will not calculate how long the Submitted → Approved transition actually took. That kind of scenario is ideally handled with a custom metric in Time Metrics Tracker: you use your own JQL as a filter, and the app then calculates the actual transition time and displays it in reports and gadgets.

JQL Is Great for Search — But Not for Time Metrics

JQL is great at answering the question, “Which issues match this condition?” But it does not answer the questions that really matter to delivery teams:

• How much time did an issue actually spend between statuses?
• Where are we losing speed?
• Which stages are creating bottlenecks?
• Which work items are aging and need attention right now?

So when a team needs more than filters — when it needs real visibility into flow metrics — another JQL trick is usually not enough. It needs a tool that calculates, explains, and visualizes those metrics clearly.

Time Metrics Tracker | Time Between Statuses does exactly that: it helps measure time between statuses, identify bottlenecks, spot outliers, control aging work, and bring all of that into Jira dashboards in a clear and actionable format.

Ready to stop guessing and start measuring?

If your team is still trying to evaluate time in status, cycle time, or transition time using only JQL, this is a good time to move from approximation to real metrics.

Try Time Metrics Tracker | Time Between Statuses to see how your workflow delays, aging issues, and status bottlenecks look in real numbers and on a dashboard — not just in assumptions.

[Bartek Szajkowski _ Orbiscend OU]

Hello,

For TimeInStatus and transitionedBy (and additional option) you can easily check with JQL, but you need JQL Argon app.

Nevertheless your app looks nice and useful.

Greetings

Bartek