IncidentHub's H1 2026 cloud and SaaS reliability report counted 30,246 outages across 1,082 providers between January and June, peaking in May with 6,070 incidents; the cloud provider category alone accounted for 4,723 outages across 86 providers. The report sums the half-year up in one phrase: dependency risk — failures cascading down through control planes, edge and CDN networks, identity providers and AI APIs.

Three Cases Worth Remembering

  • Railway, May 19, roughly 8 hours: the trigger was an automated account suspension at Google Cloud, which took down Railway's control plane, API and databases and left all Railway workloads unreachable — including those running on Railway's own metal and on AWS. Nothing was broken in the hardware sense; this was automated policy enforcement by a platform, which the report calls out as an emerging risk category of its own.
  • Google Cloud, Delhi/Mumbai data centre fire: traffic from India regions saw 21 days and 12 hours of degradation. GCP logged only 2 incidents in the half — proof that a low incident count says nothing about blast radius.
  • Azure, April 24, East US control plane down for 12+ hours: lock contention and incomplete failover. When a control plane fails the data plane often keeps serving, but you can't create, scale or modify anything — precisely the operations an incident response needs.

Two more numbers are worth filing away: Cloudflare recorded 487 incidents in the half (peaking at 98 in April), and Hetzner object storage saw 27 days 16 hours of degradation in nbg1 and 31 days 13 hours in hel1. The trend line says shorter outages are becoming more frequent — the kind that never make the news but do train your alerting into background noise.

Separate the Control Plane From the Data Plane

Most people picture "the provider went down" as the site being unreachable. The real damage is often more awkward: the site keeps serving, but you can't change anything — no scaling, no firewall edits, no certificate issuance, no console login. A usable incident plan answers two questions separately: what happens when the service is unavailable, and what happens when the service is fine but you have lost control of it.

Draw the Dependency Map (It Takes Under Half an Hour)

One row per third party, three columns: what breaks if it fails, how long replacing it takes, and whether an alternative exists.

  • DNS: the single most important thing to keep away from your CDN provider. DNS held elsewhere is what lets you route around a failing CDN at all.
  • CDN / reverse proxy: verify that your origin can serve on its own without the CDN — certificate included. Plenty of origins accept connections only from CDN egress ranges, which makes them completely unreachable the moment the CDN is the problem.
  • Certificate issuance: do you get alerted when ACME renewal fails? Is there a manually issued spare certificate anywhere?
  • Object storage and backups: at least one copy must live with a different vendor, and the restore must have been rehearsed. Multi-AZ inside one provider does not protect against account-level events.
  • The account and billing themselves: an expired payment method, a dead contact address, an automated risk flag — the Railway case shows this alone is enough to zero everything out. Re-verify billing contacts, payment methods and account verification status on a schedule.
  • Out-of-band access: SSH private keys, console recovery codes, support ticket entry points — is there a copy that doesn't require logging into the platform that just failed?

Why a Plain Independent VPS Makes a Useful Fallback Layer

This isn't an argument that self-hosting is more reliable — one machine has no multi-AZ, and dead hardware is dead hardware. But in an architecture stacked out of managed services, one instance you fully control, can SSH into directly, and that can serve static pages and basic services on its own is a genuinely useful link in the recovery chain: somewhere to host the maintenance page, a temporary origin after a DNS cutover, a second landing spot for backups. SharkCloud has nodes in Japan, Singapore, Hong Kong and the US — and putting that fallback instance with a different provider in a different region is the easiest square on the dependency map to fill in.