The Blind Spot in JQL Every Jira Team Runs Into in Reporting

[#1]

Most Jira teams reach a point where process questions start overtaking simple tracking ones. Instead of asking "which issues are open," they start asking things like "how long did that bug sit in In Progress before anyone picked it up for review?" 

It feels like a natural next step:

• open Jira
• Write a JQL query
• Get the answer

But what you get instead is a filtered list of issues with no indication of how much time passed between status transitions.

At that point, the workaround is usually manual: open individual issues, scroll through the changelog, note the timestamps, and do the arithmetic yourself. It works, but it doesn't scale, and it's the kind of task that makes you wonder why the query language isn't handling it in the first place.

The reason is straightforward. JQL was designed as a search and filtering tool, not a time-calculation engine. It can tell you that a status change occurred and when, but calculating how long an issue remained in a particular state before that change occurred is simply outside what JQL was built to do. This distinction between recording an event and measuring the duration between events is where a lot of teams run into trouble when they start building workflow reports in Jira.

What JQL Actually Does Well?

Before getting into the limitations, it's worth being clear about where JQL genuinely shines because it is a powerful query language for what it was designed to do.

JQL lets you filter and search across your Jira instance with a lot of precision. You can find all open bugs in a specific project:

project = "CORE" AND issuetype = Bug AND status != Done

You can track issues that have passed through a specific status:

status WAS "In Review" AND project = "OPS"

You can look for issues that transitioned recently:

status CHANGED TO "Done" AFTER "2024-01-01"

These are genuinely useful queries. They help teams find the right issues, build dashboards, create filters, and automate notifications. JQL handles filtering and event-tracking very well. The WAS, CHANGED, and IN operators give you access to issue history in a meaningful way.

If you want to know whether something happened, JQL can usually answer that.

What JQL Can Do Better

The boundary of JQL's usefullness becomes clear the moment your questions shift from whether something happened to how long it took. JQL can confirm that an issue moved from In Progress to Review, and it can tell you when that transition was recorded, but it cannot calculate how many days the issue spent in In Progress before that move occurred.

That distinction matters because the questions most useful to a team trying to understand its process are duration-based, not event-based:

• How long did this issue stay in Waiting for Approval on average?
• Which issues spent more than five days in In Review?
• What's the average time between Submitted and In Progress across all tickets last quarter?
• Where are issues getting stuck the longest before they reach Done?

JQL doesn't expose time-between-transitions as a queryable field, which means none of these questions has a direct answer through a query alone. The changelog in Jira stores the timestamps of every status change, but surfacing the duration between those timestamps requires something beyond what JQL is and what it was designed to provide. 

Understanding this boundary clearly is what helps teams stop trying to force JQL into a role it wasn't built for and start looking for the right layer to add on top of it.

What Teams Usually Do Instead

When teams realize JQL won't give them time-based data, they typically try a few workarounds:

1. Manual tracking. Someone opens each issue, reads through the changelog, notes the timestamps, and does the math in a spreadsheet. This works for a handful of issues. It does not scale. And it's easy to make mistakes.
2. Jira's built-in reports. Jira has some native reports — velocity charts, burn-down charts, cumulative flow diagrams. These are helpful at a high level, but they don't break down time spent per status. They don't tell you that issues are spending three days in the Blocked state on average.
3. Marketplace apps. A number of apps in the Atlassian Marketplace are specifically built to address this gap. They pull from Jira's issue history and calculate status duration programmatically, turning raw changelog data into something teams can actually use.

Tools That Fill This Gap

The practical answer for most teams is the Time in Status metric, a measure that tracks how long an issue spends in each workflow status before moving on. Unlike JQL, which surfaces events, Time in Status surfaces duration by reading Jira's changelog and converting raw timestamps into aggregated figures: average time per status, cycle time per issue, and breakdowns by assignee or issue type.

Purpose-built Marketplace apps like RVS Time in Status Report handle this without custom development. They work alongside JQL, not instead of it. You use Jira JQL to scope the issues, and the Time in Status layer handles the duration analysis on top.

How Time in Status Report Solves This Problem

Where native JQL stops, RVS Time in Status Report picks up. Rather than replacing JQL, it extends it by generating calculated custom fields (such as total time spent in In Progress or Waiting for Review) that become directly queryable through standard JQL syntax. That means you can write queries like:

"Time in Review" > 48h AND project = "CORE"

This is the kind of filtering that JQL alone simply cannot produce, because the field it's querying, Time in Review, doesn't exist natively in Jira. RVS computes it in real time from the changelog and makes it available as a first-class JQL field.

1. Reporting beyond individual issues

The add-on generates several report types that address the most common workflow analysis needs: Time in Status Report, Average Time in Status, Time with Assignee, and Cycle/Lead Time analysis. These reports surface patterns across an entire project or sprint, not just individual tickets.

1. Accurate calculations, not raw timestamps

One of the practical advantages is the ability to configure working calendars — excluding weekends, public holidays, and non-working hours from duration calculations. A ticket that sat over a long weekend shouldn't inflate your In Progress average, and this kind of configuration ensures it doesn't.

1. Custom status grouping for real cycle time

Teams often have multiple statuses that represent the same phase, In Dev, Unit Testing, and Code Review might all belong to what you'd consider the development stage. RVS allows you to group these into a single custom category and measure the combined duration, giving you a more accurate picture of actual cycle time rather than individual status counts.

1. Dashboard visibility and data exports

Reports and charts can be embedded directly into Jira dashboards as gadgets, making bottleneck detection part of the everyday workflow view rather than something that requires a separate report run. For teams feeding data into external BI tools, the add-on supports exports to CSV, Excel, and JSON, which covers most Power BI or Tableau integration scenarios.

The overall effect is that JQL remains your filtering layer, scoping the issues you care about while RVS handles the duration analysis on top of that scope. The two work together rather than in competition, and the result is a reporting setup that can answer the time-based questions that most Jira teams eventually need to address.

Conclusion

Ready to Move Beyond JQL Limitations? If your team is asking time-based questions like “how long did this take?” or “where are we getting stuck?”, you need a layer on top of JQL, not a workaround.

Start a free trial with RVS Time in Status reporting apps, extend JQL by turning raw status changes into actionable time data, helping you analyze workflows without manual effort or custom scripts.