When Technology Fails, What Should We Learn About the Service?

Major technology incidents inevitably attract attention to the component that failed. A network change, power interruption, cyber attack or software defect provides an understandable explanation for what happened technically.

For organisations responsible for critical business services, however, there is another useful question.

Complex operational incidents rarely have a single cause, and it would be inappropriate to look at an outage from outside an organisation and conclude that poor service governance caused it. Nor can stronger service architecture guarantee that failures will not occur.

Its value lies elsewhere. Major incidents provide real-world evidence of how dependencies interact, how apparently resilient components can fail together, how recovery mechanisms have vulnerabilities of their own and how disruption at one supplier or technology layer can propagate into business services far removed from the original fault.

Recent incidents provide some particularly useful examples.

Resilience is more than having redundant components

On 15 July 2026, services within Google Cloud's europe-west4-a location experienced disruption lasting 14 hours and 55 minutes following what Google described as a three-millisecond voltage drop in the incoming utility supply.

Google's incident report states that both utility power feeds were affected. One side transferred successfully to its backup power system, while the backup system supporting the other side failed to take the facility load because of electrical component failures. The power event was followed by a loss of cooling capacity, with infrastructure being shut down as temperatures rose to protect equipment and customer data. Source: Google Cloud Service Health, July 2026.

There is no suggestion that redundancy had been ignored. The facility had multiple power paths and backup systems.

The more interesting architectural lesson is that redundancy and resilience are not necessarily the same thing.

Two components only provide meaningful resilience where their common dependencies, maintenance states, operating assumptions and potential failure modes are understood. A design may appear highly resilient when viewed component by component while still containing conditions in which several safeguards can become unavailable together.

That is why service architecture should ask a slightly different question from conventional infrastructure design.

Not simply, "Do we have a backup?", but "Under what circumstances could the primary service and its backup become unavailable at the same time?"

This shifts resilience thinking from counting duplicated components towards understanding failure domains and degraded operating conditions.

Recovery arrangements have their own architecture

Microsoft's West US Azure incident on 23 July 2026 provides another useful example.

According to Microsoft's post-incident review, a break-fix repair was initiated on an optical network device. A defect in the blast-radius analysis system incorrectly expanded the scope of the repair event to include all optical devices egressing a specific data centre. Between 14:44 and 19:41 UTC, a subset of customers experienced connectivity failures, increased latency or difficulty accessing services hosted in the West US region. Source: Microsoft Azure Post Incident Review, July 2026.

The normal process included checks intended to confirm that redundant paths remained healthy before automated work took place. Following the incident, Microsoft fixed the blast-radius defect, added validation intended to prevent both diverse paths serving a data centre undergoing break-fix requests simultaneously, and scanned existing requests for similar conditions. Source: Microsoft Azure Post Incident Review, July 2026.

The useful lesson is that controls themselves form part of the service architecture.

Automated maintenance, safety checks, monitoring, rollback mechanisms and recovery tooling all depend upon assumptions about scope, connectivity, telemetry and system state. They therefore require the same architectural scrutiny as the customer-facing technology they protect.

A control that works correctly for one device may create a very different outcome if it is unintentionally applied across an entire failure domain.

This has growing commercial significance as organisations automate more infrastructure management and introduce increasingly autonomous operational tooling. Automation can reduce human error and accelerate recovery, but it can also execute an incorrect action with a speed and scale that would be difficult for a person to replicate.

The design question is therefore not whether automation should be used, but whether its authority, blast radius, dependencies, failure modes and recovery path have been consciously understood.

AI introduces interactions that are difficult to see by examining components independently

The Azure OpenAI disruption on 29 May 2026 demonstrates another emerging challenge.

Microsoft reported increased latency, intermittent failures, timeouts and HTTP 5XX errors across multiple regions. The incident was triggered by an upstream change that altered how certain capacity-related failures were surfaced. This caused a rapid increase in internal retry traffic which overwhelmed a shared inference load-balancing component. Source: Microsoft Azure OpenAI Post Incident Review, May 2026.

The post-incident review records that, in some cases, a single failed request generated up to 48 additional retry attempts. Microsoft said the amplified traffic exhausted resources in the inference-routing layer and exposed a gap in the protections applied to a large internal workload compared with many external traffic paths. Source: Microsoft Azure OpenAI Post Incident Review, May 2026.

Nothing about retrying a failed transaction is inherently unusual. In distributed systems it is normally an important resilience technique.

But resilience mechanisms can interact.

A downstream component may retry because another service failed. That service may have retries of its own. Traffic may then be redirected elsewhere, increasing pressure on another shared component. What appears sensible within each individual element can produce undesirable behaviour when those elements operate together.

This is particularly relevant as AI services become more interconnected.

A single business transaction might now involve an application, model gateway, foundation model, retrieval service, vector database, corporate information source, AI agent and several external APIs. Each component may be independently healthy and sensibly engineered.

The service can nevertheless fail because of the behaviour that emerges between them.

Service architecture therefore needs to extend beyond static dependency diagrams. It should consider transaction flows, retry behaviour, rate limits, capacity boundaries, degraded modes and what happens when one component behaves differently from the assumptions made by another.

With AI and agentic services, those relationships will become increasingly important.

Supplier resilience becomes business-service resilience

The ransomware attack against pathology provider Synnovis in June 2024 remains another valuable example because it demonstrates how disruption within one organisation can propagate into a much wider service environment.

Synnovis provides pathology services, including blood, urine and specimen testing, to NHS organisations. NHS England says the attack significantly reduced its capacity to process tests and caused delays to more than 11,000 outpatient and elective procedure appointments, with all services that had been available before the attack fully restored by December 2024. Source: NHS England.

The incident was a criminal cyber attack. The architectural lesson concerns not the cause of the compromise, but the impact of dependency upon the affected service.

Pathology may appear on an organisational chart as an external or specialist service. Operationally, however, blood testing forms part of numerous clinical pathways. A disruption to that capability can consequently affect surgery, outpatient activity, transfusion arrangements and other areas that may initially appear separate from the supplier.

This is why supplier management cannot sensibly be viewed only as a contractual discipline.

A critical supplier is part of the architecture of the business service.

Understanding that relationship means knowing not merely who supplies something and what SLA applies, but which important services depend upon it, what happens when it becomes unavailable, what alternative arrangements exist, how long those alternatives can operate and which activities should receive priority during constrained recovery.

The relevance extends well beyond healthcare.

In March 2026, the Financial Conduct Authority reported that more than 40% of cyber incidents reported to it during 2025 involved a third party, highlighting the financial sector's increasing reliance on external providers. Source: Financial Conduct Authority, March 2026.

Third-party risk is therefore potentially much more than supplier risk.

It can become service concentration risk.

Governance becomes particularly important after the first failure

The disruption affecting NATS on 8 September 2026 provides another perspective, although the incident remains under review at the time of writing.

The UK Civil Aviation Authority confirmed that a technical issue affecting the NATS flight-planning system led to delays and the cancellation of hundreds of UK arriving and departing flights. The Government asked the CAA to carry out an independent review to establish what happened and consider how well NATS is set up to deliver a resilient service in future. Source: UK Civil Aviation Authority, 9 September 2026.

Until that investigation is completed, it would be premature to draw conclusions about underlying causes.

But the incident highlights a broader principle.

Service governance is not only concerned with preventing incidents. It is also concerned with what an organisation learns from them.

A mature service environment should be able to turn previous failures, near misses, operational data and recovery experience into changed assumptions, investment priorities, architecture decisions and operational controls.

Continual improvement therefore needs to mean more than producing an incident report or completing a list of corrective actions. The important test is whether significant operational learning materially influences how the service is subsequently designed, governed and operated.

Architecture is about making risk visible before failure makes it obvious

There is a danger in analysing incidents retrospectively.

Once the sequence of events is known, solutions can appear obvious. Dependencies that were previously obscure suddenly become visible and controls that might have helped are easier to describe.

Real operational environments are considerably more difficult.

They contain legacy systems, contractual constraints, technical debt, competing investment priorities, incomplete information and combinations of failure that may never previously have occurred.

The contribution of service architecture is therefore not to eliminate uncertainty, but to make more of it visible before decisions are made.

That means understanding which business outcomes depend upon which technologies and suppliers, exposing common dependencies, challenging assumptions about redundancy, understanding recovery paths and ensuring that changes are considered in the context of the complete service rather than an isolated component.

It also means recognising that resilience has commercial limits.

An organisation could theoretically engineer extreme levels of redundancy into almost every service, but the cost would rarely be justified. Architecture is therefore partly about deciding where additional resilience creates sufficient business value and where risk is consciously accepted.

That is fundamentally different from discovering those trade-offs during an outage.

The service is what ultimately matters

Modern services are increasingly systems of systems.

They cross organisational boundaries and rely upon cloud regions, networks, suppliers, identity platforms, physical facilities, automated controls, data services and increasingly AI models and autonomous agents.

The customer or business user experiences none of those elements separately.

They experience one service.

When that service fails, understanding the technical root cause is essential. But organisations also need to understand how the disruption propagated, which other services depended upon the affected capability, whether alternative operating arrangements existed and whether recovery mechanisms remained effective under the same failure conditions.

That is where service architecture and service governance provide their value.

Not by promising that failures will never happen, and not by providing somebody to blame when they do.

Their value lies in helping organisations make more informed decisions about risk, resilience, investment, dependency and recovery before an incident forces those decisions upon them.

Recent events do not prove that stronger service governance would have prevented every outage.

They do demonstrate why understanding the service beyond the technology has become increasingly important.