Is Your Jira Dying from Custom Field Bloat?

Is Your Jira Dying from Custom Field Bloat?

Is Your Jira Dying from Custom Field Bloat?

A diagnostic guide for Jira Data Center administrators

Every Jira administrator inherits sins of the past. That dropdown field someone created years ago ‘just for one project.’ The three variations of “Priority” because teams couldn’t agree on options. The 47 fields from that plugin you uninstalled two years ago. They’re all still there. And they’re silently killing your Jira performance.
1

The Numbers That Should Worry You

Atlassian ran performance tests that every Jira admin should know about:

Custom Fields Count JQL Search Time
Baseline < 1 second
1,400 fields ~3 seconds
2,800 fields ~9 seconds
WHY THIS MATTERS

Doubling the custom field count tripled the search time. Your users won’t complain about “custom field bloat.” They’ll say “Jira is slow.” They’ll blame the server, the network, the database. But the real culprit might be sitting in your Custom Fields admin page, quietly multiplying.

2

The Symptoms You’re Probably Ignoring

Before we run any queries, let’s check if you recognize these patterns:

Search & Filters:
  • JQL queries take 2+ seconds to return results
  • Autocomplete in the search bar feels sluggish
  • Saved filters timeout on large projects
Issue Operations:
  • Creating new issues has noticeable lag
  • Opening issue detail view takes longer than it used to
  • Bulk operations crawl or timeout
Admin Tasks:
  • The Custom Fields admin page takes forever to load
  • Screen configuration feels unresponsive
  • Workflow transitions have delays
QUICK CHECK

If you’re nodding along to three or more of these, custom field bloat is likely a contributing factor.

3

The 30-Second Health Check

Let’s start with the simplest possible diagnostic. One query. One number.

If you have access to your Jira database (read-only is fine), run this:

SELECT COUNT(*) as total_custom_fields FROM customfield;

Write down that number. Now, here’s the uncomfortable truth: there’s no official “safe” threshold. But here’s what we know from the field:

Under 100 fields You’re probably fine. Normal growth for a mature instance.
100-300 fields Worth investigating. Some bloat is likely.
300-500 fields Almost certainly carrying dead weight. Audit recommended.
500+ fields Performance impact is guaranteed. Cleanup is urgent.
4

What About Jira’s Built-in Tools?

If you’re on Jira Data Center, you have access to the Instance Optimizer:

Administration → System → Instance optimizer → Custom fields optimization

This tool scans your fields and identifies those with “global context” — fields available to all projects when they’re only used by a few. It’s genuinely useful for one specific optimization.

WHAT INSTANCE OPTIMIZER WON’T TELL YOU
Which fields have never been used (zero data)
Which fields are barely used (data in <1% of issues)
Which fields are duplicates (same name, different IDs)
Which fields haven’t been touched in years
Which fields came from uninstalled plugins

For a complete picture, you need to go deeper. That’s where SQL queries come in.

5

Running Queries Without SSH Anxiety

Here’s where most custom field audit guides lose people. They assume you’re comfortable SSH-ing into your server, connecting to PostgreSQL, and running queries in a terminal.

For many Jira administrators — especially those who came from the project management side rather than sysadmin — that’s a significant barrier.

There’s an easier way.

Tools like Home Directory, Database & Log File Browser for Jira let you run database queries directly from Jira’s admin interface. No SSH. No terminal. No memorizing PostgreSQL connection strings.

0
SSH Required
CSV
Export Format
UI
Browser-Based
6

The Hidden Costs You’re Not Tracking

Custom field bloat isn’t just about search speed. Consider these ripple effects:

Index Size:

Every custom field — used or not — takes space in Jira’s Lucene index. More fields = larger index = slower reindexing = longer maintenance windows.

Memory Consumption:

Field metadata is cached in memory. Hundreds of unused fields consume RAM that could serve actual user requests.

Admin Complexity:

Ever tried to find the right “Status” field when there are four with similar names? Bloat creates cognitive overhead for your entire admin team.

Onboarding Time:

New Jira administrators inherit your mess. Every unnecessary field is documentation they need to understand and cleanup they’ll eventually need to do.

📋 Your Action Items Before Part 2

  1. Run the count query — know your starting number
  2. Check Instance Optimizer — see what Jira’s built-in tool finds
  3. Note your symptoms — which performance issues are you seeing?

This baseline will make the diagnostic queries in Part 2 much more actionable.

The Bottom Line

Custom field bloat is a slow poison. It doesn’t crash your instance dramatically — it just makes everything slightly worse, month after month, until “Jira is slow” becomes accepted reality.

The good news: it’s fixable. Not overnight, and not without some research. But with the right queries and a systematic approach, you can reclaim that performance.

Your users deserve a Jira that responds in milliseconds, not seconds.

This article is Part 1 of the “Custom Field Health Check” series for Jira Data Center administrators.

Inspired by the custom field management work of Rachel Wright (Strategy for Jira) and Rodney Nissen (The Jira Guy), whose detailed guides and SQL queries laid the foundation for systematic custom field auditing.

Scroll to Top