The Outage Ends Before the Service Does: A Ten-Day Rebuild Sequence

A major incident is declared at 06:40. Systems are restored by early afternoon. The incident log closes, the status page turns green, and the recovery plan is marked complete. By the following Tuesday the backlog has doubled, three teams are working to different priorities, and customers who were tolerant on the day have started writing to their MP.

The failure is rarely in the technical recovery. It is in the assumption that restoring a system restores a service. The operating model around the system — the queue, the priorities, the handoffs, the informal coordination that keeps work moving — has been disrupted and has not been rebuilt. The ten-day sequence below is deliberately ordered: each phase makes the next one possible.

Days one and two: contain the queue and hold the line on communication

Start with the backlog, not the root cause. Triage open work by consequence rather than age: statutory deadlines, vulnerable customers, contractual penalty clauses, safety-critical dependencies. Age-based triage is the default and it is almost always wrong after an outage, because the oldest items are frequently the least consequential.

Appoint one communications lead with authority to speak for the service, and one channel. In a UK context this matters particularly where regulators or ombudsmen are watching — a payment outage, a utilities failure or a public-facing digital service will attract attention quickly, and inconsistent messages from three teams will be remembered longer than the outage itself.

Give customers real dates rather than reassurance. We are working hard to restore normal service is not a holding line; it is an invitation to complain. Requests submitted before 06:40 on Tuesday will be cleared by Friday is a commitment you can be held to and can meet.

Days three and four: reset priority and service levels honestly

Your published service levels are now a fiction. Re-baseline against the current position rather than pretending the clock started at zero. Publish a temporary prioritisation rule, with an end date, and tell customers what has been deprioritised so they can plan around it. Silent deprioritisation is what turns a two-day incident into a two-month trust problem.

Protect the clocks that carry external consequences: complaints handling timescales in regulated sectors, statutory response deadlines in local government, waiting-time commitments in health and social care. Under the operational resilience rules that have applied to banks, insurers and investment firms since March 2025, an outage is also an evidence exercise — the impact tolerances you set in a calm year become the test you must be able to describe afterwards.

Decide explicitly what you will stop doing for a fortnight. An operations team that attempts everything at once will deliver nothing on time and will lose the goodwill it needs for the harder work in week two.

Days five and six: repair the handoffs that failed

Reconstruct the incident timeline against handoffs rather than against components. Where did work sit waiting for a decision, a permission or a person? In most post-incident reconstructions, the largest single contributor to customer harm is an interface between two teams, not a failed server.

Fix the two or three interfaces responsible for most of the delay. Where a permanent fix will take weeks, install an interim manual bridge with a named owner, a defined trigger and a review date — and put it on a register so it does not quietly become permanent. Workarounds created during recovery have a strong tendency to outlive the incident by years.

Days seven and eight: rebuild capacity and coordination

Restore effective capacity before restoring normal governance. That may mean overtime, mutual aid from a neighbouring team, or a short supplier surge with an agreed exit date. Set the exit date at the point you agree the surge, not afterwards.

Reinstate a short daily coordination rhythm — a fifteen-minute prioritisation call with the same people each morning — and plan its removal from the outset. Emergency rhythms are useful and corrosive in equal measure; they centralise decisions that should sit with service owners and they exhaust the people who attend them.

Days nine and ten: convert the review into operating model change

Separate two questions that are usually conflated: what failed technically, and what decisions were taken under pressure. The first belongs to engineering. The second belongs to operations leadership, and it is where the operating model lessons live.

Keep the review blameless but not toothless. Ask people what information they had at the time, what they were accountable for, and what they would have needed to decide differently. Publish five or six corrective actions with named owners and dates, and route the structural items — unclear decision rights, an unowned interface, a capacity model that cannot flex — into the standing operating model backlog rather than an incident file that closes.

Traps worth naming

Three recur. The hero narrative, in which individual effort is celebrated and the conditions that required it are left unchanged. The over-long report, which substitutes length for decision. And the premature return to old service levels, which restores the appearance of normality before the capacity exists to sustain it.

What day eleven should look like

A single prioritised queue, a published and temporary rule set with an end date, two repaired interfaces with owners, a visible surge plan with an exit, and a short list of changes with dates. None of that is heroic. It is simply the operating model, rebuilt deliberately — which is the part recovery plans usually leave out.