In late 2025, a single cloud region and then a single CDN's configuration change each took a large slice of the internet's applications down for hours. Most of the affected teams spent the first half hour debugging their own code.
When an application fails because a provider it depends on has failed, the most valuable thing a small team can do in the first ten minutes is establish that fact — because it changes every subsequent action: do not deploy, do not restart, do communicate, and do wait. The way to establish it is to have the provider's status on the same timeline as your own incident, automatically, so the incident opens with "Cloudflare reports a widespread outage since 11:20" attached. The AWS us-east-1 failure in October 2025 and the Cloudflare outage in November 2025 each showed the pattern: thousands of applications down, most of their teams initially convinced it was something they had shipped.
The status page update is: what users see, that the cause is an outage at a named provider, that there is no action they need to take, and when the next update is due. Do not name-and-blame; do not pretend it is nothing to do with you. "Our payment processing depends on Stripe, which is reporting degraded service since 09:40. Payments may fail. We will update when Stripe confirms recovery." — that is the whole message. The incident update template.
For agency clients, the same message per client, and the monthly SLA report marks the incident as dependency-caused — which matters for whether it counts against the tier, if your terms exclude upstream outages.
A CDN outage takes down twenty client sites at once. Twenty incidents, twenty alerts, one cause. Monitoring that understands dependencies opens the incidents — they are real; the sites are down — but marks them as explained by the provider and alerts once for the group, rather than paging the owner twenty times about something they cannot fix. The distinction is between suppressing the alert (right) and suppressing the incident (wrong: it still happened, it still goes in the report). Alert fatigue is mostly built from exactly this case.
The late-2025 outages did not mostly hurt teams because they depended on a provider — everyone does. They hurt because the teams did not know, for the first half hour, that they did. The full reliability loop.
| First question | Is it us or them — answered by vendor status on the incident timeline |
|---|---|
| During | No deploys, no random restarts, no unrehearsed failover; communicate within minutes |
| Attribution | Honest — named provider, no blame, still your incident to your users |
| Noise rule | Suppress the repeated alert, never the incident |
| Afterwards | Dependency map; providers monitored as components; degrade-not-die paths; one rehearsed failover |
| Late-2025 lesson | Most teams lost the first half hour not knowing it was upstream |
Check whether the incident started at the same time as trouble reported by a provider you depend on, whether other properties of yours that share that provider are also affected, and whether you deployed in the last hour. Monitoring that shows vendor status feeds on the same timeline as your incidents answers the first question at a glance; without it, the answer comes from status pages and news while the clock runs.
Confirm it is the provider, post a status update saying what users see and that the cause is upstream, and then wait. Do not deploy, do not restart services at random, and do not attempt an unrehearsed switch of providers. Most self-inflicted damage during dependency outages comes from trying to fix something that was never yours.
Yes, plainly and without blame: name the provider, say what users will see, say no action is needed from them, and say when you will update next. It is still your incident to your users, so do not hide behind the provider — but honesty about the cause is what keeps their trust.
That depends on your terms. Many agreements exclude upstream provider outages, some do not. Whichever it is, the monthly report should mark the incident as dependency-caused with the provider named, so the client can see the distinction — and so the decision about what counts was made in the contract rather than in the argument.
Write down every provider you depend on and what fails when it does; monitor their status as components of your own system; build degrade-not-die paths for the ones that matter most, such as queuing checkouts when payments are down; rehearse one failover a year; and know where several of your dependencies are actually one vendor.
In October 2025 a failure in AWS's us-east-1 region took a large number of services offline for hours, and in November 2025 a Cloudflare configuration change caused widespread errors across sites using its network. In both cases many affected teams spent the early part of the incident investigating their own systems before the upstream cause was clear.
Merik's Digital Operations module puts the provider on the timeline. Vendor status feeds for Stripe, Supabase, GitHub, Vercel, Cloudflare, Twilio and OpenAI are watched alongside your own assets; when an incident opens on one of your sites while a provider is reporting trouble, the incident carries that context from the start, and the alert says so. Incidents explained by a dependency are still recorded — they happened, and they appear in the monthly SLA report marked as dependency-caused — but the repeated alerting is suppressed so the owner is not paged twenty times about one CDN.
Deploys from GitHub and Vercel webhooks sit on the same timeline, so "did we ship something?" and "is a provider down?" are answered by the same view in the first minute. See the Digital Operations module.
Deploys on the timeline, reading correlation honestly, and the rollback decision.
Five causes, six rules, and the two numbers that say whether your alerts are worth reading.
Uptime 100%, users unhappy — both true. Closing the gap between server health and experience.