The 90-Minute Outage Rehearsal Your UK Cloud Team Keeps Postponing

There is a particular kind of optimism in a disaster recovery document that has never been tested. It assumes the right people will be available, that everyone will agree on what ‘major incident’ means, and that the person holding the runbook will also know which supplier contract covers the thing that just broke. In reality, the first hour of a cloud outage is less about technology and more about decisions made under pressure by people who may never have rehearsed together.

That is why the tabletop exercise matters. It is not a technical failover test. It is a decision-making rehearsal. And it is much cheaper to discover an awkward gap in a meeting room on a Tuesday morning than at 3am on a Sunday when the payment provider is down and nobody can remember who owns the comms plan.

Why a document is not a rehearsal

A DR plan tells you what should happen. A tabletop exercise tells you what actually happens when you put four or five people in a room, give them an incomplete picture and ask them to make calls in sequence. The difference is usually revealing. You find out that the support lead thought finance would approve emergency spend, that finance thought ops had a pre-approved limit, and that leadership assumed someone else was drafting the customer update.

None of those gaps are failures of technology. They are failures of coordination, and they are exactly what a 90-minute rehearsal is designed to surface.

Who actually needs to be there

The guest list matters. A tabletop with only engineers turns into a technical design review. A tabletop with only managers turns into a status meeting. You want a small group that reflects the real decision chain:

• An ops or platform lead who can explain what is broken and what recovery options exist.
• A support or service desk representative who knows what customers are seeing and saying.
• A finance or procurement person who can speak to emergency spend, supplier credits and contractual levers.
• A senior leader who can make the call on prioritisation, external messaging and risk acceptance.
• A scribe who is not also trying to fix anything.

Keep it to five or six people. More than that and the exercise becomes a seminar.

The 90-minute shape

You do not need a full day. You need a tight agenda and a willingness to let the conversation get slightly uncomfortable.

0–10 minutes: set the scene

Explain the rules. This is not a blame exercise. There are no trick questions. The aim is to find gaps, not to prove that the plan is perfect. Confirm that people can say ‘I do not know’ without it becoming a formal admission of failure.

10–30 minutes: scenario one — the cloud region wobbles

Pick a realistic scenario: a major cloud provider has degraded service in a region your team relies on. Dashboards are noisy. Some services are up, some are not. The status page says a fix is in progress but gives no timeline.

The facilitator asks: who declares an incident, and at what threshold? Who contacts customers, and with what wording? What do we stop doing to protect the recovery effort? Who speaks to the supplier, and what do we actually ask them?

The useful friction usually appears here. Teams discover that nobody has agreed the trigger for paging senior leadership, or that support is drafting updates without knowing what ops is willing to commit to.

30–55 minutes: scenario two — the identity provider locks you out

This one is often more unsettling than a cloud outage because it removes the tools you would use to fix the problem. Your identity provider is unavailable or misconfigured. Staff cannot sign in. Admin consoles are unreachable. The usual escalation path runs through the very system that is down.

The facilitator asks: how do we reach each other without email or chat? Who holds break-glass credentials, and are they actually usable today? How do we verify that a request is genuine if we cannot use normal authentication? What is the fallback for customer support if agents cannot log in?

This scenario exposes the difference between having a backup plan and having a backup plan that someone can execute without the primary system.

55–75 minutes: scenario three — a supplier fails quietly

Not every outage is dramatic. Sometimes a smaller supplier stops responding, misses a renewal, or changes terms with little warning. The facilitator asks: who owns that relationship? What is the exit plan? Which parts of our service depend on them in ways we have not documented? What would finance need to approve a rapid replacement?

The quiet supplier failure is a good test of whether procurement, ops and leadership share the same map of critical dependencies.

75–90 minutes: capture the gaps

Do not end with a vague promise to ‘follow up’. End with a short list. Who owns each gap? What is the next action? Which items need money, which need a decision, and which just need a document update? Book the next exercise before people leave the room.

Ground rules that keep it useful

A few small rules make the difference between a productive rehearsal and a performance review. Keep the scenario moving; do not let the group solve every technical detail. Ask ‘what would you do next?’ rather than ‘what should the architecture be?’. Let the scribe record decisions and assumptions, not a full transcript. And resist the urge to turn the exercise into a procurement debate — note the issue and move on.

What good looks like afterwards

You should leave with a decision log, a short list of owners, and at least one uncomfortable question that nobody had asked before. You might also leave with a revised contact tree, a clearer emergency spend threshold, or a simpler customer update template. Those are not glamorous outputs, but they are the things that make the difference when a real incident lands.

The point of the meeting-room fire drill is not to prove you are ready. It is to find the places where you are not, while the cost of finding out is still measured in calendar invites rather than lost customers. For UK teams heading into another year of cloud dependencies, that is a pretty good use of 90 minutes.