IT Disruptions

When a system stops, the service stops.

An IT disruption is any event that takes away the technology a service runs on, whether or not anyone has attacked it. Buildings and people can be fine while customers, staff and suppliers cannot do their work. The examples below run from December 2021 to October 2026 and show what that looked like for cloud platforms, a network provider, a subsea cable corridor and an airline’s service software.

This page is about faults and failures. For attacks, see Cyber Attacks. The July 2024 CrowdStrike update, which Microsoft estimated affected 8.5 million Windows devices, is on Other Risk Types.

Five common ways IT stops.

These five come up most often in continuity planning, described here in general terms. Real incidents often combine more than one.

Service outage

A platform or application becomes unreachable or returns errors, often because of a fault in its own settings, networking or dependencies.

Failed update or change

A routine change, from a trusted supplier or from your own team, behaves in a way nobody tested for and spreads before it is caught.

Data centre or cloud failure

Power, cooling, fire or physical damage takes out a building, a zone or a region, and the services built on it with it.

Telecoms or subsea cable cut

Links that carry traffic between regions are cut or congested. Services often slow down before they stop.

Third-party platform failure

A supplier’s system behind your service fails, so your service is affected even though your own systems are working.

Six habits that shorten an IT disruption.

This is general practice, not a standard, and the examples below show several of these points at work. Every organisation’s dependencies are different, so the first step is always to find out what yours are.

Map dependencies

List what each critical service needs to run, including cloud regions, DNS, sign-in, monitoring and suppliers. Several examples below began in a layer most users never see.

Set recovery time objectives

Agree how long each service can be down and how much recent data you can afford to lose, so recovery work follows what the business needs first.

Test IT disaster recovery

Practise restoring from backup and moving to a second site or region. A recovery plan that has never been rehearsed is a guess.

Keep manual workarounds

Write down how a service can run for a few hours on paper, phone or spreadsheet, and who decides when to switch.

Watch supplier and cloud concentration

Note where many services rest on one provider, region, zone or cable route, and whether that risk has been accepted knowingly.

Plan communications

Decide how staff and customers hear from you if email, chat or your own status page is down as well. In two examples below the provider’s own status or monitoring tools were affected.

Examples from the region.

September 2025Red Sea near Jeddah, Saudi Arabia, with effects across the Middle EastSubsea cable cut

Red Sea cable faults slow cloud and internet traffic

On 6 September 2025 Microsoft reported higher latency on some Azure traffic that passed through the Middle East, starting at 05:45 UTC, after undersea fibre cuts in the Red Sea. Microsoft said traffic was not interrupted but was rerouted along other paths, which added delay, and that traffic which did not pass through the Middle East was not affected. NetBlocks reported degraded connectivity in several countries and linked it to faults on the SMW4 and IMEWE cable systems near Jeddah, including effects in the UAE. Network World noted that the cause had not been independently verified at the time.

What it means for continuityA cable fault often slows a service more than it stops it, and slow can be enough to break systems that depend on fast replies. Knowing which services rely on routes through one corridor, and which can tolerate delay, helps decide what to move, pause or run locally while traffic is rerouted.

Source: Network World, 8 September 2025

March 2026United Arab Emirates and BahrainData centre damage

Cloud region in the UAE impaired after strikes on data centres

From 1 March 2026, during a regional conflict, Amazon Web Services reported that two of the three Availability Zones in its UAE region (ME-CENTRAL-1) were significantly impaired, and that one facility in its Bahrain region (ME-SOUTH-1) was affected. InfoQ reported that the third UAE zone kept operating, though some services were affected indirectly. Al Jazeera reported AWS as saying that two UAE facilities were directly struck by drones and that a strike near one in Bahrain caused physical impact. AWS advised customers with workloads in the Middle East to move them to other regions, and customers with data in Bahrain to copy critical data elsewhere. Abu Dhabi Commercial Bank said its app was unavailable because of a region-wide IT disruption, without linking it directly to AWS.

What it means for continuitySpreading a system across several zones in one region protects against many failures, but not against an event that reaches several zones at once. Recovery plans can include a second region, a view on where data may lawfully be held, and a decision in advance on when to move. It also helps to ask which of your suppliers sit in the same place.

Source: InfoQ, 18 March 2026; Al Jazeera, 13 October 2026

Examples from elsewhere.

December 2021Northern Virginia, USACloud network congestion

AWS network congestion limits control tools and monitoring

On 7 December 2021 Amazon Web Services had a service disruption in its US-EAST-1 region. AWS’s summary says an automated scaling activity at 7:30 AM PST triggered unexpected behaviour from a large number of clients inside its internal network, congesting the devices that link that network to the main AWS network. Running customer workloads were not directly affected, but functions used to create and manage resources, including launching new EC2 instances and signing in to the console, saw errors and delays. Real-time monitoring data was impaired, which slowed diagnosis, and creating support cases was affected from 7:33 AM to 2:25 PM PST. AWS reported all network devices fully recovered by 2:22 PM PST.

What it means for continuityCustomers’ running systems kept working, but the tools to change, scale and watch them did not. Plans can cover what happens when you cannot launch, change or even see your systems, and how you reach a supplier when its support route is also affected.

Source: Amazon Web Services, 10 December 2021

June 2025Global, including Doha and Dammam among the locations listedCloud API errors

Google Cloud API errors after a policy data change

On 12 June 2025 Google Cloud, Google Workspace and security products had increased 503 errors on external API requests. Google’s incident report says a policy change containing blank fields was replicated globally within seconds and reached a code path added on 29 May 2025 that lacked error handling, which put its Service Control component into a crash loop. Google’s mini report gives a start of 10:49 and an end of 13:49 Pacific time, with every region except us-central1 mitigated about two hours in. The full report says us-central1 took up to about two hours and forty minutes to resolve fully. Google said its status page was itself affected at first, and that some customers’ monitoring on Google Cloud was also failing. Its status page lists Doha and Dammam among the affected locations.

What it means for continuityA change to shared data reached every region at once, so having several regions did not help. Customers who ran their monitoring on the same platform lost sight of the incident as well. Keeping monitoring and communication channels outside the platform they watch is a low-cost way to stay informed.

Source: Google Cloud Service Health, incident report, 13 June 2025

October 2025Northern Virginia, USACloud DNS fault

DNS fault in a core database service spreads across AWS US-EAST-1

From 11:48 PM PDT on 19 October to 2:20 PM PDT on 20 October 2025, AWS’s US-EAST-1 region had a disruption with three distinct periods of impact. AWS’s summary traces the trigger to a latent race condition in the DNS management system for DynamoDB, which left an incorrect empty DNS record for the regional endpoint and caused higher DynamoDB error rates until 2:40 AM. Dependent services followed. Between 2:25 AM and 10:36 AM new EC2 instance launches failed, and between 5:30 AM and 2:09 PM some network load balancers saw more connection errors. AWS noted that EC2 instances launched before the event stayed healthy, and that customers with DynamoDB global tables could still reach replica tables in other regions.

What it means for continuityOne dependency inside a provider’s platform can reach many services built on it, and full recovery can take far longer than the first fault. Existing capacity kept working while the ability to add more did not, so plans can say what to run on what is already up. Replicas in another region helped the customers who had them.

Source: Amazon Web Services, post-event summary, October 2025

November 2025WorldwideProvider configuration fault

Cloudflare network fails after a configuration file doubles in size

From 11:20 UTC on 18 November 2025 Cloudflare’s network failed to deliver core traffic, and visitors to many customers’ sites saw error pages. Cloudflare’s report says it was not caused by a cyber attack. A change to database permissions caused a bot management feature file to double in size, which exceeded a limit in the software that routes traffic. Cloudflare first suspected a large attack, then stopped the file spreading and put an earlier version back. Core traffic was largely flowing by 14:30 UTC and all systems were working normally by 17:06 UTC. Cloudflare also reported that most users could not log in to its dashboard and that authentication to its Access service failed widely until a rollback began.

What it means for continuityMany organisations depend on a service like this without having chosen it directly, because it sits in front of a website, login or application. Cloudflare’s first diagnosis was an attack, which shows why teams keep an open mind when a fault and an attack look alike. Knowing which services pass through one provider, and how to reach your own systems if it fails, is a place to start.

Source: Cloudflare, 18 November 2025

October 2026London, United KingdomData centre power event

Power event at a London cloud facility disrupts banks and public services

On 20 October 2026 Google reported a power event at a third-party facility in its europe-west2 region in London, affecting the europe-west2-b zone, with disruption starting shortly after 6am UK time. The Guardian and the ABC named Revolut, HSBC, Lloyds and Halifax among those with problems, although Lloyds said its app was working. They also reported effects on remote court hearings that use the Courts and Tribunals Service Cloud Video Platform and, according to Downdetector, on Royal Mail. The Guardian also reported temporary glitches on the NHS app. Revolut said customers’ money and data were safe. Google said services had been restored and that it would publish an analysis once its investigation was complete.

What it means for continuityServices that look separate can share one cloud zone. The effects were mostly within the UK, so where a provider’s facility sits matters as well as who the provider is. Clear messages to customers and a manual route for services such as remote hearings reduce harm while the cause is still being established. This entry follows what Google had said when the page was written.

Source: The Guardian, 20 October 2026; ABC News, 20 October 2026

October 2026Texas, USAThird-party software

Airline boarding and baggage software goes offline

On 9 October 2026 Southwest Airlines delayed more than 1,200 flights, which FlightAware put at 27 per cent of its flights, and cancelled about 40, after third-party software used to check baggage and board passengers went offline, according to KERA. The airline said the software was back by 12:30 pm and that the early hour helped it limit the effect on the rest of the day. Dallas aviation officials described an intermittent internal network outage affecting boarding pass printing and mobile app scanning.

What it means for continuityA supplier’s system at the point of service can slow a whole operation even when the company’s own systems are working. Fixing it early in the day limited the effect. Written manual fallbacks, practised before they are needed, help staff keep customers moving while a supplier restores service.

Source: KERA, 9 October 2026