E3S World All articles
Emerging Systems

Failover Is a Verb: The UK’s Redundancy Rehearsal Gap

E3S World
Failover Is a Verb: The UK’s Redundancy Rehearsal Gap

Photo: NASA / JPL-Caltech / Space Science Institute, Public domain, via Wikimedia Commons

Redundancy has become a line item. UK organisations in 2026 can point to secondary cloud regions, backup data centres, dual-fed substations and standby control rooms with justified pride. Yet the presence of spare capacity is not the same as the ability to use it. The gap between buying resilience and being able to fail over to it is now one of the more consequential blind spots in UK operations — and it is rarely closed by procurement alone.

The warm standby illusion

A warm standby is only warm if someone has recently touched it. In practice, many UK estates hold redundant infrastructure in a state best described as ambient: powered, patched intermittently, and assumed to be ready. The assumption survives until an incident forces a cutover.

Cloud regions offer a familiar example. Teams architect for multi-region resilience across UK South and a secondary region, but failover often depends on quota increases that were never pre-approved, DNS changes that were never rehearsed, identity replication that has drifted, and data sync jobs whose lag has never been measured under load. When an outage arrives, the recovery plan becomes a discovery exercise.

Local government services show a similar pattern. A council may retain a secondary data centre or a contracted recovery site for revenues and benefits, adult social care and payment systems. But the runbooks are frequently written by a supplier, stored in a document library, and tested only in an annual exercise that is announced weeks in advance. Staff who would execute the switch have often changed roles since the document was approved.

Critical operational technology (OT) environments raise the stakes further. Water treatment works, substations and transport control rooms may hold redundant programmable logic controllers and communications links. But failover to manual operation depends on trained people being on site, with the right authority and the right isolation procedures. Where rotas have been thinned, the redundancy exists on the schematic and not on the shift.

Why switchability degrades quietly

Four forces erode the ability to fail over, and none of them appear on a procurement scorecard.

The first is configuration drift. Runbooks age faster than infrastructure. A documented step that once took two minutes can take twenty after an authentication change, a firewall rule update or a supplier platform migration.

The second is staffing and decision rights. Failover often requires someone to make a call under uncertainty: invoke the standby, accept data loss, or escalate. If the authority to act is unclear out of hours, the standby remains unused while the incident unfolds.

The third is supplier obligation. Contracts frequently promise recovery time objectives without requiring evidence of participation in cutover drills. The obligation to assist may be qualified by “commercially reasonable efforts”, which is not a testable standard when the clock is running.

The fourth is drill design. Announced, scripted exercises test the script. They do not test the capability. A drill that succeeds because the supplier’s account team was pre-warned and the on-call engineer had the runbook open an hour beforehand has demonstrated something useful, but not switchability.

A switchability test regime

The remedy is not more redundancy. It is a disciplined regime that treats failover as an engineered, rehearsed capability. Four pillars are worth adopting across cloud, local government and OT estates.

1. Runbook currency and usability

Runbooks should be version-controlled, owned by a named individual, and tested by someone who did not write them. Each should include a rollback path and a clear statement of what “success” looks like at each stage. A useful rule is that no runbook should be older than six months without evidence of a walkthrough.

2. Staffing and decision rights

Failover requires a named incident commander and a rota that is tested, not merely published. Decision rights should be explicit: who can invoke the standby, who can accept data loss, who can authorise supplier escalation. Training records should show that at least two people per shift can execute the critical path.

3. Supplier obligations and evidence

Contracts should require supplier participation in cutover drills, provision of evidence after each drill, and remediation of failures within an agreed period. Recovery time objectives should be paired with a tested cutover time and a named escalation route. “Commercially reasonable efforts” should not be the only standard for a service that a public body depends on.

4. Drill evidence and closure

Drills should be semi-announced or unannounced, with time-to-switch recorded, failures logged, and remediation actions tracked to closure. The output should be a short evidence pack that a board, an auditor or a regulator can read: what was tested, what broke, what changed. Regulators including Ofgem, Ofwat and the NCSC increasingly expect evidence rather than assertion, and sector resilience forums are moving in the same direction.

Making it routine

Resilience should be managed like safety: scheduled, observed and reported. That means a standing calendar of cutover drills, independent observation, and board-level reporting on switchability rather than on spare capacity. It also means accepting that a failed drill is a useful result, provided it is closed out.

The question for UK operations leaders in 2026 is not whether they have a standby. It is when they last proved they could switch to it, how long it took, and what broke. An unrehearsed failover is a single point of failure disguised as redundancy.

All Articles

Related Articles

The Unglamorous Endpoint: Why UK Estates Need a Copper-Exit Register, Not Just a Switch-Off Date

The Unglamorous Endpoint: Why UK Estates Need a Copper-Exit Register, Not Just a Switch-Off Date

The Drift Ledger: Contracting for AI Maintenance That Ages in Service

The Drift Ledger: Contracting for AI Maintenance That Ages in Service

The Integration Will: Why UK Public Tech Must Plan for the Vendor’s Exit

The Integration Will: Why UK Public Tech Must Plan for the Vendor’s Exit