How can I improve Jira performance for large projects with thousands of issues?

Question

Hi everyone,

Our team has been using Jira to manage several large projects, and we've noticed that boards, filters, and issue searches have become slower as the number of issues has grown. We're trying to identify whether this is caused by project configuration, custom fields, automation rules, or something else.

What are the best practices for improving Jira performance when working with large projects? Are there any recommended settings, maintenance tasks, or reporting strategies that help keep Jira responsive without affecting day-to-day workflows?

I'd appreciate any tips or official recommendations from those who have managed large Jira instances.

Gabriela - LeanZero · Answer

Trudy and Viswanathan have basically covered the hygiene side already (archiving, trimming custom fields, auditing apps), so instead of repeating that I'll point at the thing that's usually hiding behind "it got slow as the issue count grew" - because on Cloud it's often not the issue count at all.

Two different problems tend to get lumped together as "Jira is slow", and they have completely different fixes, so it's worth figuring out which one you actually have.

If it's the boards and backlogs specifically that crawl: that's almost always the board's saved filter returning too many items. Atlassian's guardrails put the point where a board or backlog starts truncating and dragging at around 5,000 work items in a single board, and most boards sail past that because the filter never drops finished work. The fix isn't deleting anything - it's narrowing what the board renders. Take the board's current filter and add:

... AND statusCategory != Done

or, if people still want recent done items visible, a rolling window like:

... AND (statusCategory != Done OR resolutiondate >= -30d)

The done issues stay in the project untouched, they just stop being rendered on the board. That single change is usually what takes a sluggish board back to instant.

If instead it's every issue search and the whole instance that feels heavy: that one scales with your custom fields far more than your issues. The number of custom fields - and especially how many are on a global/default context so they apply everywhere - is what bloats the index and every search; a few thousand issues barely registers next to that on Cloud. So the high-leverage cleanup there is hunting down unused custom fields and over-broad contexts, rather than archiving issues.

Fast way to tell which camp you're in: time a board load against a plain search like project = YOURKEY ORDER BY created DESC. If the board is the slow part but that raw search is snappy, it's the board-filter/5k thing. If both are slow, start with custom fields and apps.

Which is it for you - the boards, or everything across the board?

Viswanathan Ramachandran · Answer

hi @Sarang Ali

It depends on multiple factors and rarely a single cause. It could be slow and expensive JQL, number of custom fields and third party apps (its gadgets and configurations)

If you're on data centre, check the DB maintenance (involve DBAs), your underlying infrastructure (CPU, JVM, memory, disk IOPS, Garbage collection)

Check and monitor your Jira index health. On a quiet time, try running Jira in safe mode and see if it makes a difference.

If you're stuck, you can enable the debug logs and check with Atlassian support for expertise.

Trudy P Claspill · Answer

Hello @Sarang Ali

Welcome to the Atlassian community.

Are you using Jira Data Center or Jira Cloud? Go to your Help button in Jira (near your avatar) and from it select About Jira. What do you see for a version number?

There are several things that can impact performance. If you are on Jira Data Center then the underlying infrastructure can impact performance.

The number of issues can impact performance. It is recommended that projects that are no longer being used be Archived. That removes the issues from the search index which will speed up search related functions.

If the projects are active but contain many old issues, you can alternately look at archiving the oldest issues.

Filters that retrieve large numbers of issues to populate agile boards, dashboards, and other reports will suffer decreasing performance as the number of issues being retrieved grows.

Having a large number of fields on your screens for issues can impact the load time for issue views.

The use of third party apps can impact performance and specific tasks.

Automations can impact performance depending on how they are triggered, how often they execute, and how many steps they have to execute.

The actual best practices and mitigation options will depend on with product you are using (DC vs. Cloud), the factors above, and where specifically you are seeing performance degradation.