Cloud Outages 2025: Monitoring Third-Party Dependencies

What 2025 showed: three outages that took down half the web

The three most prominent incidents of the year shared a signature: one internal, in itself mundane trigger at a single provider propagated through dependent services and hit thousands of websites that had done nothing wrong. In the US-EAST-1 outage on 20 October 2025, a latent race condition in a database service's DNS management set off a cascade that dragged instance management and networking down with it and lasted around 15 hours (AWS). Estimates of insured losses from that single incident ranged up to 581 million US dollars (CyberCube). Just nine days later, a faulty configuration change at a major content-delivery service caused a roughly 8-hour outage (Microsoft). And on 18 November a database permission change doubled an internal configuration file until the traffic routing of a central edge network hit an internal limit and failed for a good 3.5 hours - full restoration dragged on into the early evening (Cloudflare).

Notably, none of these outages was caused by an attack - they were internal faults set off by routine changes (AWS, Microsoft, Cloudflare). For operators that carries an uncomfortable truth: even technically excellent providers occasionally fail, and your own reachability hangs on links in a chain you can neither see nor control. A single provider used by many at once becomes a shared risk: when it goes down, everyone relying on it goes down with it.

Why third-party dependencies become single points of failure

A modern website is not a self-contained system but a web of services. The median desktop page embeds 83 third-party requests, and on mobile it is 79 (Web Almanac 2025). Each of those calls is a dependency: a nameserver, a CDN, a font library, a payment provider, a login provider, an analytics or map component. If a single critical link fails, the whole page can become unusable even though your own web server responds flawlessly.

The load-bearing links right at the front of the chain weigh heaviest. DNS and CDN decide whether a visitor finds and is served your page at all. They sit in front of your web server, and therefore outside your own health checks. This is exactly where the worst outages of 2025 struck: a name-resolution fault in a cloud region dragged entire service landscapes down (AWS), and an edge network refused to deliver thousands of sites (Cloudflare). Payment and login APIs are critical too: if payment stalls, revenue collapses even while the catalog still loads. That is why DNS and domain monitoring and the checking of embedded programming interfaces belong to monitoring just as much as the homepage itself.

What an outage really costs

Downtime is not a purely technical topic but a revenue question. According to the ITIC 2024 survey, a single hour of downtime costs more than 300,000 US dollars for over 90% of mid-size and large enterprises (ITIC 2024). Among larger enterprises, 41% say an hour of downtime devours between 1 and over 5 million US dollars (ITIC 2024) - and that excludes litigation or contractual penalties. For a small online shop the absolute figure is smaller, but relative to revenue a multi-hour outage on a promotional day hits just as hard.

On top of the direct loss of income come indirect costs that linger longer. Support channels flood, because customers cannot tell whether the problem is on their side or yours. Trust erodes when visitors repeatedly hit error pages and find no explanation. And search engines factor in user experience: repeated unreachability and timeouts can indirectly affect visibility and ranking. A multi-hour outage is therefore not just a lost afternoon but an event with a long tail.

The blind spot: when your server is up but customers see nothing

The most dangerous gap appears where the monitoring comes from the very infrastructure it is meant to check. An internal health check happily reports green because the web server responds - while DNS, CDN or a central API in front of it has already failed and no visitor gets through. The dashboard shows normal operation, yet the phone rings anyway. This is precisely the pattern that marked the big incidents of 2025: your own code ran, but the chain in front of it was broken. Only a measurement from the outside, from an independent region, exposes this blind spot.

Monitoring third-party endpoints deliberately

The first practical step is a list of every external service that matters to running the business. For each of them you can define a dedicated check that runs from several regions at short intervals. If the service fails, you see it at the root rather than at the symptom on the homepage. A simple, machine-readable basis looks like this:

[
  { "name": "DNS / nameserver", "type": "dns",  "target": "example.com",                  "interval_s": 60 },
  { "name": "CDN asset",        "type": "http", "url": "https://cdn.example.com/health",   "expect": 200 },
  { "name": "Payment API",      "type": "http", "url": "https://api.pay.example/status",   "expect": 200 },
  { "name": "Login / auth",     "type": "http", "url": "https://auth.example.com/healthz", "expect": 200 }
]

Besides the reachable HTTP endpoints, it pays to watch services that should actively report in themselves - nightly imports, payment reconciliations or backups. If such a signal fails to arrive, that is just as alarm-worthy as a direct error. Monitoring via heartbeats, which fires when the pulse is missing, catches these silent lapses. What matters when scoping the checks:

• DNS and domain: monitor name resolution, nameserver responses and expiry dates so a change or failure at the registrar or DNS provider does not slip by unnoticed.
• CDN and edge: fetch a small health asset through the delivery network to catch edge outages ahead of the homepage.
• Payment and login: check the status endpoints of the critical APIs, because this is where revenue hangs directly on a third party.
• Certificates: keep short lifetimes and automatic renewal in view - more in the piece on 6-day certificates in SSL monitoring.
• Multiple regions: run every check from different locations so a regional network fault is not misread as a global outage.

A status page that broadcasts even while your server is up

When a site goes down, customers want to know one thing above all: is it me or you, and when will it be fixed? A public status page answers that before the first support request arrives. The decisive point is that it runs independently of the monitored infrastructure. If it sat on the same server or behind the same CDN, it would go down at the very same moment - and be useless precisely when it is needed most.

A good status page shows the live state of components, documents past incidents with timestamps and lets customers subscribe to notifications - by email or feed. That shifts communication from reactively working through individual requests to actively informing everyone affected at once. It relieves support in exactly the hour when it is under the greatest pressure.

Redundancy and runbooks: resilience is more than monitoring

Monitoring is the detection layer - it shortens the time to reaction but does not prevent the outage. Resilience only emerges in concert with prepared measures. These include a second nameserver at an independent provider, short DNS time-to-live values for quick failover, a fallback path for delivering static content and a clearly documented runbook that dictates step by step who does what in an emergency. It is important to rehearse these contingency plans regularly rather than merely filing them - an untested plan typically fails at exactly the moment it counts.

A resilience roadmap in five steps

1. Inventory dependencies: list every external service your page depends on - DNS, CDN, payment, login, fonts, analytics. Without this map nothing can be secured.
2. Monitor from the outside: check the homepage and critical endpoints from several regions instead of relying on internal health checks that stay green during an outage.
3. Set up a status page: run a status page separate from your own infrastructure, with subscription and incident history, so customers stay informed even during a total outage.
4. Define alert paths: decide who is notified via which channel and what happens if nobody responds - including an escalation stage.
5. Rehearse contingency plans: keep a runbook current and drill the emergency so the response holds in a real incident instead of being improvised.

Setting up external monitoring and a status page with XICTRAQ

The outages of 2025 left a lesson: availability is not a state you establish once but a chain you have to watch continuously. Because the critical links often lie outside your own control, the uptime monitoring of third-party endpoints belongs in the toolbox just as much as watching your own homepage. Detect, communicate, respond - in that order the damage is contained.

XICTRAQ checks your website and its embedded third-party endpoints from several regions, alerts across multiple channels and runs a status page that broadcasts independently of your infrastructure. So you see an outage at its root, inform customers actively and record the incident for later analysis - instead of reading it off falling order numbers. How to monitor domain and DNS data reliably is covered in the piece on RDAP in domain monitoring.

Start with a free trial and check which third-party endpoints actually carry your page today. Or book a personal demo to see monitoring, alerting and the status page working together.