Reoccurrence detection
An issue you marked Fixed should stay fixed. Reoccurrence detection watches for that promise being broken: when a genuinely new occurrence lands on a fixed issue, Log Lens automatically flips its status to Reoccurred and records why. You don't have to babysit closed issues to know when a bug comes back.
How it works
Every ingested event is grouped into an issue by its fingerprint, and each new occurrence is stored against that issue. When a new occurrence is recorded for an issue whose current status is fixed, Log Lens:
- Transitions the issue to
reoccurredand stampsstatus_updated_atwith the current time. - Writes an entry to the issue's status history:
| Field | Value |
|---|---|
from_status | fixed |
to_status | reoccurred |
note | A new occurrence was detected during log import. |
The transition is fully automatic and happens during log import - there's nothing to enable. See Workflow status and history for the full status model and how to read the history trail.
What triggers it
Only a new occurrence triggers the transition. Occurrences are deduplicated on ingest, so re-reading a log file you've already indexed does not count - the duplicate is ignored and no status change occurs. This means reoccurrence reflects a real, newly-seen event rather than reprocessing.
The transition also only applies to issues currently in fixed status. An issue that is open, resolved differently, or already reoccurred is left untouched by this rule.
new occurrence recorded
│
▼
issue status == 'fixed' ?
├── yes to status = 'reoccurred', history entry written
└── no to status unchanged
Why it matters
- Regression signal. A fixed issue turning red again is a strong hint that a deploy reintroduced a bug or a fix was incomplete.
- Audit trail. The history note tells you exactly when and why the status changed, without guessing.
- No manual polling. You close issues with confidence and let ingestion surface anything that comes back.