Who gets called, and what they are told

An escalation path written during an incident is a negotiation, and the person with the most to lose wins it. So it gets written in the calm week, agreed in writing, and stored where the on-call person can find it at 2am without asking anyone.

Four levels, defined by consequence

Levels defined by time are unhelpful, because a five-minute outage of an internal report and a five-minute outage of a payment path are not the same event. Define them by consequence and let time follow.

Level	Trigger	Who is called	Expected response
L1	A feature is degraded; work continues	FDE on rotation	Same business day
L2	A business process is blocked for a group of users	FDE + customer's process owner	Within the hour
L3	Money, safety, or a regulated record is affected	Both sides' leads, in writing	Immediately, by phone
L4	Data loss, breach, or public impact	Executive sponsors, security, legal	Immediate, no waiting for a diagnosis

Two rules make the table real. First, the customer's process owner is named in it — not "the business", a person, with a phone number that has been tested. Second, anyone may escalate one level above what they think is needed, and the cost of an unnecessary escalation is a conversation, not a reprimand. An organisation where people are afraid to wake someone up discovers its incidents late.

What the update says

Every update has the same two sentences plus a time: what we know is confirmed, what we are doing next, and when you will hear from me again. Nothing else, until there is something else.

Three things do not go in an update. A cause, before it is confirmed — the first story becomes the official story and it is usually wrong. A promised fix time, unless you know the cause. And any phrasing that assigns blame, including the soft forms ("an operator entered..."), because blame changes behaviour in the direction of hiding information.

What the FDE may commit to

The role's authority is usually unclear in the first incident and clear afterwards. Settle it before: what can be done without asking (rollback to the last known-good version, disabling a feature, restoring from backup), what needs the customer to say yes (anything that touches their data or their other systems), and what is never a field decision (changing the contract, promising compensation, speaking to their regulators).

The single most useful pre-agreed permission is disabling the deployed feature. A deployment that cannot be switched off is not a deployment; it is an outage waiting for a date.

The review, seven days later

Not the same week. The people who fixed it are still exhausted, and the people who were affected are still angry; both produce narratives rather than findings.

The output is a document with a timeline (observed and inferred separated, as in debugging on site), one to three causes, and one to three changes with owners and dates. A review that ends with "be more careful" has produced nothing, because carefulness is not a control.

Three tests for whether the review was real:

• Would the same thing happen again tomorrow? If yes, no change was made.
• Did the change land in a system — a check, a guard, an alert — or in a person's memory?
• Did anyone outside the incident team read it?

What this does to the commercial side

Incidents are where deployments are lost, and they are lost less by the outage than by the silence around it. A customer who was called before they noticed the problem will describe the vendor differently for years; a customer who discovered it themselves will describe the vendor accurately and badly.

The same review list feeds the four-week rule: a feature that caused an L2 or above and now sits above a thirty percent disable rate is not alive, and the honest thing is to remove it rather than keep it as a memorial. What survives the deployment at all, and under what terms, is settled in the sunset clause.