Where does your team's time actually go? Jira still can't tell you natively.

[#1]

JRACLOUD-90221, open since 2016, asks Atlassian for something that sounds basic but still isn't built: a report that shows how long issues spend in each status across a project — not one issue at a time, but as an aggregate you can sort and filter. It's been in Gathering Interest for close to a decade and still has 243 votes and 186 watchers.

What's missing, specifically

Open any single Jira issue and you can click into the History tab and see its individual status transitions — timestamps for every move from To Do to In Progress to Done. That's useful for one issue. It's useless for a project. There's no built-in way to answer questions like:

• Which issues have been sitting in In Review longest, right now?
• What's the average (or P90) time issues spend in Blocked this quarter?
• Which project, of the five we run, has the worst average time-in-status for bugs specifically?

The ticket's requesters ask for exactly this: sorting issues by time spent in a status, breaking it down by assignee (to spot where individual workloads back up) and by project (to spot which teams or workflows are structurally slower) — in short, turning per-issue history into a project-level diagnostic.

Why this is a harder ask than it looks

The raw data already exists — every status transition is in the issue's changelog via GET /rest/api/3/issue/{key}/changelog. The hard part is aggregating it: computing working-day durations per status, per issue, across potentially thousands of issues, fast enough to render as a report instead of timing out. That's a fundamentally different computational shape than most of Jira's built-in reports (which mostly count or bucket issues by a field value, not by elapsed time between two changelog events). It's a reasonable guess — not something Atlassian has stated — that this is part of why the ticket has stayed in Gathering Interest for years rather than being scheduled.

Working around it today

Short of the native report, teams either:

1. Pull and compute it manually from the changelog API — accurate, but doesn't scale past small samples and has to be redone every time.
2. Use the per-project Control Chart report, which shows cycle time trends but not a per-status, per-assignee breakdown across a JQL filter.
3. Use a dedicated time-in-status Marketplace app that pre-computes this from the changelog and exposes it as a filterable table with percentiles.

Full disclosure: I work for the company behind CycleLens, an app in that third category — a JQL-filterable table of time spent in every status, per issue, with P50/P75/P90 percentiles and CSV export, built specifically because this exact gap (project-level time-in-status aggregation) doesn't exist natively yet.

If this is a gap your team feels too, the ticket is still open — vote and watch JRACLOUD-90221. Atlassian has said it isn't actively planned, but continues collecting feedback, and tickets like this have moved before when interest kept climbing.