Jira's Control Chart vs time in status — how to actually find the bottleneck

Jira’s Control Chart (company-managed boards only) plots cycle time per completed issue as a scatter chart with a rolling average — a trend line for “are we getting faster?”, not a bottleneck-finder. It gives one blended number per issue, not a per-status breakdown, so it can’t tell you an issue took 9 days because it sat 4 of them in Code Review. Time in status can: it sums the status transitions in the issue history into a per-stage duration, so the slow step gets named instead of guessed. Here’s the difference in detail, and when each one is the right tool.

What Jira’s Control Chart does — and doesn’t

The Control Chart (on company-managed boards) plots cycle time: the total time issues took from a start column to a done column, with a rolling average. It’s genuinely useful for a high-level “are we getting faster or slower” trend.

Where it stops short when you’re hunting a bottleneck:

• One number per issue, not per status. The per-status split is exactly the thing that points at the problem, and the Control Chart doesn’t have one.
• One board, company-managed only. It’s scoped to a single board’s columns, and isn’t available the same way on team-managed projects. You can’t ask “time in status across everything matching this JQL.”
• Coarse working-time handling. It has a toggle to exclude whole non-working days, but doesn’t model partial days, shifts, or a custom holiday calendar — so unless that toggle is on, evenings and weekends inflate the numbers, and even with it on, holidays still don’t count.

So the Control Chart is a trend line, not a bottleneck-finder.

The number you actually want: time in status

Jira does record every status transition in each issue’s history — it just never adds them up for you. “Time in status” reporting does that sum: for each issue (or each status across many issues), how long it actually spent in To Do, In Progress, In Review, Blocked, and so on.

That’s the view that answers the real questions:

• Where is the drag? “Issues spend an average of 3.1 working days in Code Review” is a bottleneck you can act on.
• Is anything aging right now? Which open issues have sat too long in one status past your threshold.
• Cycle and lead time, correctly. Total flow time with a working-calendar applied, so weekends and off-hours don’t distort it.

This is what Linger is built to surface — time-in-status, cycle time and the current bottleneck, with a working calendar, across any issues you can express in JQL, answer-first on the issue and in a report.

Which should you use?

• Want a high-level “are we speeding up?” trend on one board? The native Control Chart is fine.
• Need to pinpoint which status is the bottleneck, or report across any JQL with correct working-time? That’s a time-in-status app like Linger. See how to see time in status and how to measure cycle time.

The tell is simple: if you’re staring at a cycle-time chart trying to guess which stage is slow, you want the per-status breakdown — that’s the number the Control Chart doesn’t give you.