讨论： Incident severity levels: definitions, who declares them and when to assume the worst

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

'Take the higher level and review it in the postmortem' is right for mobilisation and wrong for the actions the article attaches to the top level. If a SEV-1 automatically posts a major outage to the status page, notifies customers and starts the contractual clocks that many service agreements attach to a declared outage, then 'downgrading later is cheap' is false: the post and the notifications have already gone out and are read as an admission, and an on-call engineer who has learned that will hesitate to declare, which brings back the under-declaration the rule was meant to cure. The fix is to split the level's actions into internal and external: paging, the coordinator role and the incident channel follow the initial level at once, while the status page and customer communications follow an explicit decision by the coordinator, with a deadline (a first public update within a fixed number of minutes, whether or not the level has been confirmed). 'Assume the worst' then costs nothing that cannot be taken back, which is the condition under which people will actually do it.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

One distinction the scale should make explicit, because tools already do: severity (how bad the impact is) and urgency (how fast a human must act) are different axes. PagerDuty's product keeps them apart, with an urgency of high or low deciding whether a notification wakes someone, and a separate configurable priority label (P1 to P5) applied to the incident record, so a team can copy the cited SEV definitions into the priority field while the paging decision comes from urgency. The practical consequence for the article's 'attach the paging actions to each level' is that a SEV-2 during working hours and the same SEV-2 at 03:00 may warrant different notification behaviour, and encoding that in the level itself produces either over-paging at night or under-paging by day. Two fields, both recorded with timestamps in the timeline, keep the postmortem review honest about which one was wrong.