Why isn't there a cycle time gadget for the Jira dashboard? (and what to do about it today)

[#1]

If you've ever wanted to glance at your team's cycle time the same way you glance at a burndown or a pie chart — from the dashboard, without opening a separate report — you're not alone. JRACLOUD-94942, open since 2013, asks for exactly this: "It would be useful to have the cycle time on a gadget on the dashboard, it would be easier this way." It's sat in Gathering Interest for over a decade and still has 241 votes and 103 watchers — which tells you the itch hasn't gone away.

Why doesn't Jira have this natively?

Jira's built-in dashboard gadgets (Pie Chart, Two Dimensional Filter Statistics, Created vs. Resolved Issues Chart) are built around counts and status snapshots, not duration between two points in time. Cycle time — the elapsed time between when work starts and when it finishes — isn't a field on the issue; it's a derived value that has to be computed from the issue's status-change history (the changelog). A dashboard gadget that shows it would need to read and aggregate that changelog for every issue in scope, which is a meaningfully heavier computation than the count-based gadgets Jira ships with. It's a reasonable guess — not something Atlassian has stated — that this is part of why it's been sitting in Gathering Interest: not because the request doesn't make sense, but because it's a different class of feature than the rest of the dashboard.

The built-in workaround, and where it falls short

Jira does have one native tool that gets close: the Control Chart on classic/company-managed projects, which plots cycle time per issue over a date range. It's useful, but it lives inside the Reports section of a single project board — not the dashboard — so it doesn't give you the at-a-glance, cross-project view people are asking for in this ticket. It also only covers one project's board at a time, and doesn't break results down by an arbitrary JQL filter (e.g. "just bugs," "just this quarter's epic," or "across these three projects"). (Jira Cloud also ships a separate, similarly-named Cycle Time Report tied to deployment tracking — it measures the DevOps chain from first commit to deployment, not status-to-status duration, so it doesn't cover this ticket's ask either.)

What people actually do in the meantime

Until there's a first-class gadget, teams typically fall back to one of:

1. Manual export — pull the changelog via GET /rest/api/3/issue/{key}/changelog for each issue and compute start/end timestamps in a spreadsheet. Works, but doesn't scale past a handful of issues and has to be redone every time you want a fresh number.
2. The Control Chart report, accepting its per-project, per-board scope.
3. A dedicated time-in-status app from the Marketplace, most of which compute cycle time (and lead time, and time-per-status) from the same changelog data, pre-aggregated so it's fast across large result sets, and exposed as a JQL-filterable table rather than a single-project chart.

If you're evaluating that third option, that's the category my employer's app, CycleLens, competes in — full disclosure, I work for the company that builds it. It won't put cycle time on the dashboard either (same architectural reason Atlassian hasn't: computing it well needs pre-aggregation, not a lightweight gadget query), but it gives you a JQL-filtered, cross-project cycle time table with percentiles today, without waiting on this ticket.

Either way — if a cycle time dashboard gadget would genuinely help your team, go vote and watch JRACLOUD-94942. Tickets like this move when Atlassian sees sustained interest, and it's been open since 2013.