How to Calculate Time in Status at Scale in Jira (Without Waiting Forever)

[#1]

Time in Status sounds simple.
You look at an issue, you see how long it stayed in each status, you aggregate that, done.
That’s how it looks when you test it on a small project.
Then you run it on something big.
And suddenly:

it takes forever

results look off or inconsistent

or it just doesn’t finish

What changed isn’t the feature. It’s the amount of history behind it.
Time in status is basically a reconstruction problem. For every issue, you need to go through all its status changes, in order, and calculate durations between them. Now multiply that by hundreds of thousands or millions of issues.
That’s where things blow up.
Most implementations try to handle it in one pass: load a big set of issues, process all transitions, calculate everything, then return the result. That’s fine until the dataset crosses a certain size. After that, it either becomes extremely slow or just stops working reliably.
You’ll see the usual patterns:

progress bars that move and then get stuck

calculations that take minutes (or much longer)

suggestions to “reduce the dataset”

At that point, it’s not really usable anymore. Not because the idea is wrong, but because the execution doesn’t hold up.
What made more sense to me was to stop treating this as a single big calculation.
Instead, keep the same idea of controlled processing. Work on a defined set of issues, process their transitions, and make sure that operation actually completes in a predictable way. Once you have that, you can build on top of it—filter, export, analyze—but you’re not gambling every time you run a report.
There’s also another thing that shows up at scale: workflows are rarely clean. You don’t just have a straight line from “To Do” to “Done”. You get loops, reopens, skipped statuses, custom transitions. All of that makes the calculation heavier and harder to generalize.
So the goal is not just to calculate time in status, but to do it in a way that doesn’t fall apart when the data is messy and large.
That’s basically the approach I took with Time in Status Reporter for Jira:
And it’s not separate from everything else I mentioned before. Same idea shows up in the other tools:

– Issue History & Snapshots Reporter for Jira
– Advanced Comment Search for Jira
– Issue Insights (bundle) 

– Assets History & Snapshots Reporter for Jira

Same pattern, different type of data.
The problem isn’t calculating time. It’s doing it at scale without the whole thing turning into a waiting game or failing halfway through.

Disclosure: I am part of the team that build these apps.