Jira Search Returns Stale or Missing Issues: Diagnosing the Lucene Index

You just created or edited an issue, the direct URL opens it fine, but a JQL search or board refuses to show it. That specific pattern — data exists, search doesn't see it — almost never means lost data or a permissions problem. It means Jira's search index is stale, backlogged, or damaged. This guide walks through recognizing the condition, isolating the cause, applying the right fix, and knowing when to stop and escalate.

Why search and storage disagree

Jira stores issues in its relational database, but JQL queries and boards read from a separate Lucene index — an inverted text index maintained on disk under the Jira home directory (typically <jira-home>/caches/indexes). Every create, edit, transition, or comment fires an indexing event that updates Lucene asynchronously or near-synchronously. When that pipeline stalls, the database is correct and the index is not, which is exactly the symptom above.

Confirm the symptom is search-only

Before touching anything, verify the hypothesis. It takes two minutes and prevents you from rebuilding an index over a permissions problem.

1. Open the missing issue by its direct URL (/browse/PROJ-123). If it loads with current field values, the database is fine.
2. Run a JQL query that must match it, e.g. key = PROJ-123 or updated >= -10m ORDER BY updated DESC. If it returns nothing, search is stale.
3. Ask another user to run the same query. If they also can't see it, it's indexing, not a permission scheme or board filter.

If the issue doesn't load by direct URL either, stop here — you have a different problem (data integrity or permissions), and reindexing won't fix it.

Cause and diagnostic table

Ordered checks

Work top-down; each step either identifies the cause or narrows the next one.

1. Open the Indexing administration page (Administration → System → Indexing; exact menu names vary by version). Note the queue depth and the last reindex timestamp. A deep queue with an old timestamp means backlog, not corruption.
2. Search the application log (<jira-home>/log/atlassian-jira.log) for IndexingService or Lucene exceptions around the time issues went stale. Read the stack trace — a plugin class name in it changes your fix entirely.
3. Test a single-issue reindex. From the issue view or admin tools, reindex one missing issue, then re-run the JQL. If it appears, the index mechanism works and your problem is scope (backlog or dropped events), not a broken index.
4. Check disk health. Confirm free space on the volume holding the index directory and check I/O latency. A full or failing disk both corrupts indexes and slows reindexing.
5. In Data Center, compare nodes. Run the same JQL through node-specific access (bypassing the load balancer) and compare result counts. Divergence points at replication, not the index itself.

Fixes matched to findings

Queue backlog

Let background indexing drain — watch the queue depth fall on the admin page. If a specific project was bulk-changed, trigger a project-level reindex instead of waiting for the global queue. No downtime required.

A few missing issues

Reindex the affected issues or their project. This is cheap and safe to do during business hours.

Widespread staleness

Run a background reindex from the Indexing admin page. Search stays available (against the old index) while a new one builds. If inconsistencies persist afterward, escalate to a lock-and-rebuild (foreground) reindex — but understand the cost: search is unavailable for the entire run, which on large instances can take hours. Schedule it in a maintenance window and announce it.

Corrupt index

If the log shows Lucene corruption errors and reindexes keep failing, rebuild from scratch:

1. Stop Jira completely and confirm the process is gone (a half-stopped node can still write partial index files).
2. Back up the index directory, then remove it.
3. Start Jira and run a lock-and-rebuild reindex.

This is destructive by design — the backup is your only rollback if something interrupts the rebuild. Verify afterward by re-running the JQL queries that were failing and confirming the queue drains to zero.

Data Center node lag

Restart the affected node so it pulls a fresh index snapshot from a healthy node. Then re-run the per-node JQL comparison to confirm result counts converge. If they never converge, treat it as a replication fault, not an indexing fault.

Plugin-caused failures

If stack traces name a plugin's custom field or indexer, reproduce with apps disabled (safe mode) before blaming the core index. If indexing succeeds in safe mode, re-enable apps in batches to isolate the offender, then engage the vendor.

End-to-end verification

Don't declare victory on a finished progress bar. Create a test issue, confirm it's missing from a matching JQL, reindex it, and confirm it appears — that proves the whole pipeline works. Then check the Indexing admin page for queue depth at zero and a fresh last-reindex timestamp, and scan the log over the next day for recurring Lucene exceptions to confirm the root cause is resolved rather than masked.

Preventive engineering decisions

• Put the index directory on fast local storage. Network filesystems are a recurring source of corruption and latency.
• Schedule full reindexes in low-traffic windows after large bulk imports or workflow migrations.
• Avoid habitual full reindexes in production — lock-and-rebuild blocks searching, so treat it as a planned operation, not a routine fix.
• Monitor index queue depth so backlogs are caught before users report them.

When to escalate to Atlassian support

Escalate rather than iterate when: a reindex repeatedly fails or stalls at the same percentage; corruption recurs after a clean rebuild (suspect disk or memory hardware — run diagnostics on the host); Data Center index replication never converges across nodes; or plugin indexer errors persist even in safe mode. Attach the relevant atlassian-jira.log excerpts, your Jira version and deployment type (Server vs. Data Center), and the timeline of bulk changes — it shortens the support loop considerably.

One caveat: admin menu names, index paths, and replication behavior differ across Jira versions and between Server and Data Center. Confirm the specifics against the documentation for your installed version before running destructive steps.