Incident severity is stamped once at creation and never re-evaluated #17

New Issue

2026-08-19T22:41:30-04:00

logan commented

2026-08-19 22:41:30 -04:00

An incident's severity is written when the incident is created and never updated as later calls arrive.

That makes it wrong for exactly the incidents that matter most: anything that escalates. A call that opens as routine and becomes a structure fire keeps the severity it was born with, so every severity-driven sort, filter and colour in the UI misrepresents it. The "Major only" filter on /incidents will omit a major incident that did not start that way.

Found during the UI design pass (UI_REDESIGN.md). It matters more under the redesign, where severity drives the worst-first ordering of the incident rail on the home screen — a stale severity would silently bury a live emergency below routine traffic.

Fix direction: re-evaluate severity on each linked call and keep the maximum, or recompute from the incident's calls when the summary is regenerated. Decide explicitly whether severity can ever go down (an incident downgraded after more information) or is monotonic — the answer changes the implementation and should be written down.

An incident's `severity` is written when the incident is created and never updated as later calls arrive. That makes it wrong for exactly the incidents that matter most: anything that escalates. A call that opens as `routine` and becomes a structure fire keeps the severity it was born with, so every severity-driven sort, filter and colour in the UI misrepresents it. The "Major only" filter on `/incidents` will omit a major incident that did not start that way. Found during the UI design pass (`UI_REDESIGN.md`). It matters more under the redesign, where severity drives the worst-first ordering of the incident rail on the home screen — a stale severity would silently bury a live emergency below routine traffic. Fix direction: re-evaluate severity on each linked call and keep the maximum, or recompute from the incident's calls when the summary is regenerated. Decide explicitly whether severity can ever go *down* (an incident downgraded after more information) or is monotonic — the answer changes the implementation and should be written down.

logan referenced this issue from a commit

2026-08-19 22:57:24 -04:00

Re-evaluate incident severity on link, stamp resolved_at at every resolution site

logan closed this issue

2026-08-19 22:57:24 -04:00

logan commented

2026-08-19 22:57:53 -04:00

Fixed in commit 70d63abeaa on Server main. Severity is re-evaluated in _update_incident on every call link via a new _max_severity() helper, merged as max(current, new) on the four-level ladder. Decision: monotonic — severity only ever rises, never falls, as calls attach. An incident briefly assessed major genuinely was major at that moment; status/resolved_at (see #18) are what retire it, not a later calmer-sounding call. Full rationale is in the _max_severity docstring in incident_correlator.py. New tests in tests/test_correlator_gate.py cover the escalation case (routine -> major) and confirm a later routine call does not downgrade a major incident.

Fixed in commit 70d63abeaaa24a56aa6fd3cbc6320e50e9f77b98 on Server main. Severity is re-evaluated in _update_incident on every call link via a new _max_severity() helper, merged as max(current, new) on the four-level ladder. Decision: monotonic — severity only ever rises, never falls, as calls attach. An incident briefly assessed major genuinely was major at that moment; status/resolved_at (see #18) are what retire it, not a later calmer-sounding call. Full rationale is in the _max_severity docstring in incident_correlator.py. New tests in tests/test_correlator_gate.py cover the escalation case (routine -> major) and confirm a later routine call does not downgrade a major incident.

logan added the area/correlation

labels 2026-10-05 02:04:19 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: logan/server-26#17