Skip to content

feat(incidents): the timeline leads with what is worst, not what is newest - #485

Merged
passcod merged 1 commit into
mainfrom
feat/incident-severity-ordering
Aug 5, 2026
Merged

feat(incidents): the timeline leads with what is worst, not what is newest#485
passcod merged 1 commit into
mainfrom
feat/incident-severity-ordering

Conversation

@passcod

@passcod passcod commented Aug 4, 2026

Copy link
Copy Markdown
Member

🤖 The incident timeline was ordered by time alone, so an operator opening a page mid-incident had to read a chronology to find the failure — and a warning filed a minute ago sat above a failure that had been going for an hour.

Issues are now ordered by the severity of their effective result, ties broken by most recent, with notes below every issue:

✖ failed   disk_free      2h ago
✖ failed   db_connect     6h ago
▲ warning  pg_tuning     10m ago
● passed   sync_lookup    1h ago
─────────────────────────────
🗒 note  felix            5m ago

Effective rather than observed, so a check an operator capped at warning ranks as a warning here too — the same result the rest of the incident workflow acts on. The rank comes from CHECK_RESULT_ORDER, already the UI's severity vocabulary, rather than a second ordering to keep in sync.

An issue with no recorded result predates the check-state model and has no severity to rank on, so it sorts below everything graded — where indexing an unknown directly would have put it first.

Coverage

Two Playwright specs, seeded so that time-ordering alone would produce the opposite order: one over the full timeline (failure above warning above recovered above note), one over the Issues filter. Assertions key off the issue message, which is the row's always-visible summary — the check name only renders in the expanded provenance line, and recovered issues render collapsed.

seedIncidentNote is new; notes had no seed helper.

…ewest

The incident timeline was ordered by time alone, so an operator opening a
page mid-incident had to read a chronology to find the failure — and a
warning filed a minute ago sat above a failure that had been going for an
hour.

Issues are now ordered by the severity of their effective result, ties
broken by most recent, with notes below every issue. Effective, not
observed: a check an operator capped at warning ranks as a warning here
too, matching what the rest of the incident workflow acts on. The rank
comes from CHECK_RESULT_ORDER, already the UI's severity vocabulary, and an
issue with no recorded result predates the check-state model and has no
severity to rank on, so it sorts below everything graded rather than above
it — where an unknown lands if you index it directly.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@passcod
passcod added this pull request to the merge queue Aug 5, 2026
Merged via the queue into main with commit 6c95bed Aug 5, 2026
7 checks passed
@passcod
passcod deleted the feat/incident-severity-ordering branch August 5, 2026 02:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant