How I started measuring cycle time in Jira — and why I ended up building a tool for it

[Thomas]

I'm a team lead running a Kanban team on Jira Cloud. About a year ago I wanted to answer a simple question: How long does it actually take us to finish a ticket once we start working on it?

Turns out Jira doesn't have a cycle time field. The Control Chart gets close, but it measures time in board columns, not status transitions and if your board groups multiple statuses into one column, you lose granularity. Velocity charts measure story points per sprint, which tells you about estimates, not duration.

The data I needed was already in Jira, every status change is timestamped in the issue history. But surfacing it as an actual metric meant pulling that history via the API, deciding which transitions count as "start" and "done" for our workflow, and computing the distribution.

I started with spreadsheets. Exported changelogs, calculated elapsed times, built charts. It worked, but it was tedious and I had to redo it every week.

So I built a desktop app to automate it: Cylenivo . It connects to Jira, reads the full status transition history for every ticket, and gives you what Jira won't show natively:

• Cycle time and lead time with P50, P70, P85, P95 percentiles

• Throughput trends over time

• Monte Carlo delivery forecasts ("When will we be done?" with confidence levels instead of single-date guesses)

• Flow efficiency (what share of cycle time is active work vs. waiting)

• Rework detection (tickets that looped back through statuses)

It's free, open source, and runs entirely on your machine. No cloud, no account, no telemetry. All data stays in a local SQLite database. Works on Mac, Windows, and Linux. There are also community plugins for Trello and OpenProject.

Full disclosure: I built this tool. I'm sharing it because I think the problem is real. Most Jira teams I've talked to either don't measure cycle time at all, or cobble together manual exports. If that's you, give it a try and let me know what you think.

Some guides that explain the thinking behind it:

• How to measure cycle time in Jira  - what cycle time means and why Jira's built-in reports fall short

• Lead time vs cycle time  - why both matter and what the gap between them tells you

• Monte Carlo forecasting  - why single-date estimates fail and how throughput-based simulation works

• Flow metrics explained  - the five numbers that actually matter

• Getting started guide  - connect Jira and get your first dataset in 5 minutes

Curious how other teams handle this. Are you measuring cycle time? If so, how? Custom dashboards, third-party apps, spreadsheets? Would love to hear what works for you.

[Tomislav Tobijas]

Hi @Thomas ,

Well, from my experience people tend to use Marketplace apps if they want to build more advanced reports where this might also fit in.

I know that my colleague did build a Forge app that kinda stores information about 'cycle times' in specific custom field where you can then use that for additional reporting - either within or outside Jira.

Now, Jira dashboards are relatively limited, so I would also suggest new Home dashboards to see if something like that is supported there. On that note, if you are on Enterprise, it is most likely that you could built everything in Atlassian Analytics (maybe even with native fields and data as well).

Lastly, we did a couple of implementations where customers use PBI or similar tools for Jira-related reporting.

Cheers, Tobi

[Thomas]

Thanks for the answer!