Users can’t find old tickets in our internal search. What are the first things to check?

First things to check, in order:

1. Index freshness / reindexing

   • Are old tickets actually being indexed?
   • Check the last successful full/incremental reindex time.
   • Verify no indexing backlog or failed jobs.

2. Retention / archival rules

   • Were old tickets moved to an archive, cold store, or separate index?
   • Confirm the search service includes archived sources.

3. Search filters and defaults

   • Is the UI filtering by date, status, assignee, queue, or “recent only” by default?
   • Look for hidden filters like “last 90 days,” “open only,” or tenant-specific scoping.

4. Permissions / ACLs

   • Can the affected users see the tickets in the source system?
   • Search may omit items the user lacks permission to access.

5. Query behavior / relevance

   • Are old tickets not matching because the search is keyword-only or stemming/tokenization changed?
   • Check whether exact IDs, email bodies, or attachments are indexed.

6. Data source completeness

   • Confirm the tickets still exist in the source system and weren’t deleted/purged.
   • Check whether migrations changed ticket IDs or fields used for indexing.

7. Time range and pagination

   • If the UI or API has a default time window, expand it.
   • Make sure pagination/infinite scroll isn’t hiding older results.

8. Recent changes

   • Any changes to analyzers, schema, ranking, permissions, or connector config?
   • Roll back or compare against the last known good configuration.

Quick triage:

• Search a known old ticket by exact ID.
• Search as an admin vs. a normal user.
• Check whether the ticket appears in the raw index/API.
• Verify the old-ticket corpus count in the index matches the source system.

If you want, I can turn this into a step-by-step debug checklist or a decision tree for support engineers.