How to Make Jira Reporting Work at Scale (Without Crashes or Timeouts)

[#1]

If you’ve only worked with smaller Jira projects, reporting feels… fine. You run a query, maybe export something, maybe build a report, and that’s it.

The problems only show up later, and not all at once.

At some point the data grows and things start getting weird. Queries that used to take seconds now take minutes. Pagination starts to feel slow. You try to run something a bit heavier and it either hangs forever or crashes after a long wait. And eventually you hit that message everyone has seen at least once: “please reduce your dataset”.

That’s usually where people stop and accept it as a limitation. Either Jira, or the app they’re using.

After dealing with this for a while, I don’t think the problem is Jira itself, and it’s not just “bad apps” either. It’s mostly the way this kind of reporting is typically built.

Most tools follow the same pattern: load the data, process it, show the result. That’s completely fine when the dataset is small. But once you get into hundreds of thousands or millions of issues, “load everything” just stops being realistic. It either takes too long, or fails somewhere in the process, or gives you something that only worked this one time but not the next.

Pagination is often presented as the fix, but in practice it doesn’t really solve much. Having “next” and “previous” is ok if you have a handful of pages. When you’re dealing with thousands, it becomes almost useless. You’re not navigating anymore, you’re just clicking and waiting.

What ended up working for me was basically accepting that the whole “process everything at once” idea has to go.

Instead of trying to load and process everything upfront, you load just enough to get started and then build things as the user moves through the data. If someone jumps far ahead, the system catches up instead of freezing. It’s not magic, it just means you don’t try to solve the whole problem in one step.

Another thing that becomes obvious pretty quickly is that JQL is not enough for certain types of analysis. It’s great for a lot of things, but when you start digging into history or comments in detail, you hit its limits. At that point the only practical option is to work on a controlled set of issues and then do the deeper filtering in memory. Not the cleanest approach on paper, but it’s predictable and it doesn’t fall apart under load.

The part that people tend to push back on is limits. There’s this expectation that a tool should handle “everything”. In reality, if you don’t define boundaries, the system will define them for you—through timeouts, crashes, or inconsistent results. Putting limits in place deliberately isn’t about restricting users, it’s about making sure things actually complete and behave the same way every time.

Once you structure things like this, the difference is not that everything becomes infinitely fast or unlimited. It’s that it becomes stable. You know roughly how it will behave. You don’t sit there wondering if this run will finish or die after 30 minutes.

This is the direction I ended up taking while building apps around Jira data, mainly:

– Issue History & Snapshots Reporter for Jira

– Time in Status Reporter for Jira

– Advanced Comment Search for Jira

Bundle (Issue Insights):

They cover different use cases, but the underlying approach is the same.

Disclosure: I’m part of the team that built these apps.