Paste your custom field list. You get one ready-to-run JQL query per field, and a verdict on each once you type the counts back in. Everything runs in your browser — nothing is sent anywhere.
Paste your custom fields below to get started.
Jira has no report for this. The queries here are the manual version of one.
One per line. Any of these shapes work — the field id is all that is really needed, a name just makes the table readable.
customfield_10122 Confluence (migrated)
10122, Confluence (migrated)
customfield_10122
10122
In Jira: Settings → Issues → Custom fields. The id is in the URL or the … menu of each field.
Counting — run both passes to tell a dead field from an abandoned one.
| Field | Query to run in Jira | Issues | Verdict |
|---|---|---|---|
| Nothing pasted yet. | |||
is not EMPTY works on every field typeWe ran this against a live Jira site with 39 projects and years of accumulated configuration. The query form below returned a count for every field type we tried — select lists, text fields, multi-user pickers, checkboxes, team, sprint, number, cascading select. Not one type refused it. If you have heard that some custom field types cannot be queried, that is worth re-testing; it did not hold up.
The date clause is not optional. Without it Jira rejects the query outright with "Unbounded JQL queries are not allowed here. Please add a search restriction to your query." Adding AND created > "1970-01-01" satisfies the restriction while still matching everything, because no Jira issue predates it.
This is the part worth knowing, because it explains why your instance still has dead fields after you ran a cleanup tool.
Most tools — including Jira's own Site optimizer — define "unused" as "not attached to any project, screen or context." Atlassian's documentation says so directly, and notes that this is different from identifying fields with no issues. So a field that sits on twenty screens and has never once been filled in counts as used. It will not appear in the list. That is exactly the field you were looking for.
The attachment method also fails in the other direction, and this one is dangerous. A field used across a great many projects often has no project-specific context — just the global default. Attachment-based tools read that as "no context" and offer it up for deletion, even though thousands of issues depend on it. Admins have reported this against both the native optimizer and paid cleanup apps.
Counting values sidesteps both problems. A global context does not change the count, and a field nobody filled in has a count of zero no matter how many screens it appears on. That is the whole idea behind the queries on this page.
Neither method is complete on its own. Attachment tells you who could use a field; values tell you who did. Deciding to delete needs both, which is why the verdicts here say "candidate".
If your site came from Jira Server or Data Center, the migration almost certainly left fields behind. On the site we tested, three of them looked like this:
| Field | Issues with a value |
|---|---|
| Confluence (migrated) | 0 |
| TestRail (migrated) | 0 |
| Test server 3 (migrated) | 0 |
| Sprint | 12,391 |
| Team | 2,272 |
Search your list for migrated, imported, old, copy, (1), and the names of tools you no longer run. That is where the empty ones cluster, and it is the fastest way to shorten a list of hundreds down to something you can actually review.
This matters more than the count itself, so it is worth being blunt: a zero here makes a field a candidate, not a casualty. A field with no issue values can still be:
Treat the list as a shortlist to review by hand. The count tells you where not to spend that time.
The custom fields admin screen lists what you have. It does not tell you which of them are empty — so the only way to find out natively is to open a field, build a query, read the number, and repeat. At forty fields that is a slow afternoon. At four hundred it does not happen at all, which is why instances quietly accumulate them for years.