When a data centre goes dark, the cause is usually power. When a data centre stays online, but workloads stop responding, the cause is almost always the network. The first kind of failure makes headlines. The second kind costs organisations real money quietly, in the form of degraded latency, packet loss, dropped sessions, and slower response times that users notice before any monitoring dashboard does. Both deserve attention, but it's the second category where the gap between assumed resilience and actual resilience tends to be widest.
The September 2024 designation of UK data centres as Critical National Infrastructure, and the forthcoming Cyber Security and Resilience Bill that follows from it, are about to make that gap a regulated concern rather than an internal one. This article sets out how we approach network resilience as an engineering discipline at Carbon-Z, what genuinely improves it, and the failure modes that catch even well-prepared operations off guard.
What network resilience actually means
Network resilience is often treated as a synonym for redundancy. It is not. Redundancy is a tactic. Resilience is the property of a system that continues to deliver its intended service when something inside it fails. The two are related, but they're not interchangeable, and the difference matters because plenty of doubly-redundant networks fall over in ways that resilient networks do not.
A useful working definition has three components. The network needs to detect that something has gone wrong, fast enough that the affected traffic can be rerouted before users notice. It needs to fail over cleanly, without sending half the traffic into a black hole or creating routing loops. And it needs to recover to a stable state once the underlying fault is fixed, without introducing a second outage in the process. Most network designs handle one or two of these well. Doing all three, consistently, under realistic load, is harder than it looks.
The shifting threat picture
For most of the last decade, the network was not the headline risk. Power was, and still is. The UK government's own assessment of data centre resilience estimates that outages cost the UK industry low single-digit billions annually, with £0.7 billion in lost productivity for customers in 2019 alone, and points specifically to the July 2022 failure of two data centres serving an NHS trust during a heatwave as evidence of the systemic risk. Power tends to dominate those incidents, but IT and network-related issues are an increasing share of the total, and the share has been rising as architectures grow more complex.
Three trends sit behind that shift. The first is architectural complexity: software-defined networking, network function virtualisation, and overlay protocols have made networks more flexible but also more interdependent, which means more places where a misconfiguration can cascade. The second is third-party dependency: even on-premises deployments now rely on external DNS, certificate authorities, BGP route announcements from upstream providers, and cloud-hosted control planes, all of which sit outside any one operator's direct control. The third is the emergence of AI workloads, where large training jobs depend on tightly coupled GPU communication across high-bandwidth interconnects , and a brief network glitch can cost hours of compute progress.
Network resilience now means designing for problems that originate beyond the rack as well as inside it.
The principles that genuinely move the needle
Network resilience is the cumulative result of a handful of design principles applied consistently, alongside a great deal of disciplined detail.
Diversity is more important than duplication. Two fibre paths in the same trench provide almost no resilience against the most common cause of fibre failure, which is mechanical damage during construction work. Two paths in physically separate routes, ideally with different ingress points to the building, are an order of magnitude more useful. The same logic applies to power feeds for network equipment, upstream carriers, and, where it can be arranged, separate Autonomous Systems carrying the routes.
Failover paths must be tested under load, not just tested. A switch that handles failover correctly with no traffic on it tells you very little about how it will behave at 80% link utilisation when a primary path drops. Realistic load testing surfaces buffer exhaustion, convergence-time edge cases, and control-plane CPU saturation that quiet tests miss entirely.
Configuration drift causes more outages than equipment failure. Most network outages classified as "human error" in post-mortems are configuration drift caught by a change that exposed the underlying inconsistency. The Uptime Institute Annual Outage Analysis 2025 found that failure to follow procedures rose by ten percentage points as a contributing cause of outages compared with the previous year. Network configuration management should be source-controlled, peer-reviewed, and validated against a known-good template before deployment. Monitoring for drift between actual and intended state matters as much as monitoring for outright failure.
Observability has to extend beyond your perimeter. The point at which you find out a key transit provider is dropping packets should not be the point at which your customers tell you. Synthetic monitoring of upstream paths, BGP route monitoring, and active probing of dependencies you don't own are how you find out first.
Common failure modes worth designing against
Some patterns recur often enough across post-mortems that they are worth listing explicitly:
Asymmetric routing after failover , where traffic leaves through one path and returns through another, often breaks stateful firewalls and load balancers in subtle ways
Convergence storms , where a single link failure triggers cascading reconvergence across multiple routing protocol domains, multiplying the disruption
DNS resolution depends on the very service that has failed , which prevents recovery from completing because the systems needed to coordinate it cannot resolve each other
Untested certificate expiry , which causes services to fail in ways that look like network problems but are not
Spanning Tree Protocol misconfigurations , which remain a leading cause of broadcast storms in environments that still rely on flat Layer 2 segments
Time synchronisation drift , where NTP failures cause logs, security tokens, and distributed databases to disagree about reality
Each of these is straightforward to design against once you know how to look. The pattern they share is that they sit at the boundary between disciplines, where network and application teams each assume the other has it covered.
How connectivity choices shape resilience
The decisions that most affect long-term network resilience are usually made before the first packet is sent. Choosing a colocation environment with multiple carriers on site, diverse fibre routes into the building, and the option to peer directly with cloud providers gives you architectural options that no amount of clever configuration can substitute for later. Choosing a single-carrier environment, or one where the building has a single fibre ingress, locks in a ceiling on the resilience you can ever achieve.
Carbon-Z provides carrier-neutral Connectivity Services within our colocation environments, with access to Tier 1 and Tier 2 networks, alongside the immersion, direct-to-chip, and air-cooled compute infrastructure we operate. Our facilities are ISO 27001 certified, which is directly relevant to the security and resilience baseline that the new regulatory regime will require. The point of bundling connectivity into the colocation conversation rather than treating it as a separate procurement is that the network and the facility have to work together when something goes wrong. A diverse fibre path is only as resilient as the cross-connect arrangement and the rack-level redundancy supporting it.
If you are scoping a new deployment or reviewing the resilience of an existing one, a free power assessment is the easiest starting point. We will walk through the network architecture, the upstream dependencies, and where the realistic single points of failure sit.
What changes under the new regulatory regime
The Cyber Security and Resilience Bill, working through Parliament, will bring data centres formally into the Network and Information Systems regulatory regime. The practical effect for operators will be statutory duties around incident reporting, security and resilience measures, and notification to Ofcom as the operational regulator. The detail is still being finalised, but the direction is clear: network resilience is moving from a commercial differentiator to a regulated baseline.
Operators planning new infrastructure investments now should assume that the regulatory floor will rise during the lifecycle of the deployment. Designing for what is currently best practice rather than what is currently mandatory is the prudent default. The cost of retrofitting resilience into a network architecture is typically several times the cost of building it in from the start, and the disruption involved usually exceeds whatever the original cost saving was.
Network resilience, like most engineering disciplines, is the cumulative result of many small, deliberate decisions made consistently. There is rarely a single intervention that transforms a fragile network into a robust one. The work is in the layered detail, applied early.