Checkout starts failing. Before anyone can fix anything, somebody has to answer one question, and everything downstream depends on it.
Is this our code, or is a provider having a bad day?
If it's ours, you're rolling back or shipping a fix. If it's theirs, you're switching on a fallback, writing a status update, and waiting. Completely different afternoons, and the wrong guess costs you the first twenty minutes.
The annoying part is that the two look identical from your own error logs. Timeouts, 5xx responses, retries piling up. Nothing in that tells you which side of the boundary the fault is on.
You have more of these than you think
A typical application in 2026 depends on 3 to 7 cloud infrastructure providers, 5 to 15 third-party APIs, and another 2 to 5 SaaS tools sitting in the critical path. Payments, auth, email, SMS, CDN, feature flags, whatever AI features you've added recently.
And 75% of IT leaders name third-party dependency as their most common downtime trigger. Not their own code. Somebody else's.
The volume is real too. One aggregator recorded more than 48,000 outages across hundreds of SaaS and cloud services in 2025, with cloud and hosting providers making up about 22% of them.
The maths nobody does
Here's the bit that reframed this for me, and it takes ten seconds to check on your own stack.
Your availability isn't the average of your dependencies' SLAs. It's the product of them.
Five services at 99.9% each gives you 99.5% composite. That's over four extra hours of downtime a year that you didn't cause and can't fix, arriving on somebody else's schedule.
Add a sixth dependency and the number gets worse. Nobody runs that calculation when they add an integration, because adding one takes an afternoon and the cost shows up as a fraction of a percent eighteen months later.
The cascades are real too. Netlify builds have broken because GitHub authentication failed. SendGrid has reported delays caused by Gmail. Your dependency's dependency is also your dependency, and you almost certainly haven't mapped that layer.
Status pages will not save you
The instinct is to open the vendor's status page. It's the wrong first move, and the timing data explains why.
Status pages lag reality, sometimes by 30 to 90 minutes. One monitoring service reported detecting 45 outages up to 3.6 hours before vendors acknowledged them in April 2026 alone, plus 104 incidents that vendors never publicly reported at all.
Which makes sense if you think about who updates them. A status page is a communications decision made by a company under pressure, not a monitoring signal. All green means nobody has posted yet.
So during the window where you actually need the answer, the official source is usually silent.
What actually answers the question
Two things, and neither is exotic.
The first is knowing which of your services talk to which external providers. Sounds obvious. Try asking it quickly. "Which of our services would break if the payment provider went down" is a question most teams answer by asking around, and the answer is usually incomplete, because integrations get added by whoever needed one and nobody maintains a list.
This is where I lean on Vorr AI. Because it holds the relationships between services, code and infrastructure rather than just querying each system separately, "what does this service depend on, and what depends on it" is a question rather than an investigation. When checkout starts erroring, I can see what's underneath it before I start guessing, including the external edges.
The second thing is the shape of the errors themselves, and this is the fast heuristic.
If it's yours, the errors cluster around whatever changed. One service, one endpoint, often one deploy. If it's theirs, the errors cluster around a provider, cutting across services that otherwise have nothing to do with each other. Three unrelated services all failing on outbound calls at the same second is not three bugs.
That distinction takes about thirty seconds if you can see across your services at once, and about twenty minutes if you're opening dashboards one at a time.
Things worth doing before you need them
Tag every external dependency in your code, however crudely. A consistent client wrapper or a naming convention means you can find them later. Grep-ability beats documentation because it can't go stale.
Monitor the dependency yourself rather than trusting the status page. A cheap synthetic call against the provider, from your own network, gives you a signal before anybody publishes anything.
Add circuit breakers on anything non-critical. If your recommendation provider goes down, that should be a missing panel, not a failed checkout. This is the difference between degrading and falling over, and it's mostly a config decision you make in advance.
Work out your composite number once. Multiply the SLAs of everything in your critical path. Whatever comes out is your actual ceiling, and it's a useful thing to have in your pocket next time someone asks why you can't promise four nines.
The question at the start never goes away. But the time it takes to answer is almost entirely determined by work you did on a quiet afternoon, and not at all by how hard you think when it's on fire.
Author note
Manjunaathaa, Associate DevOps Development Engineer at Frigga Cloud, working on Vorr AI.
The composite SLA thing genuinely bothered me when I first worked it out for our own stack. Every individual number looks fine. Four nines, three nines, all reassuring in isolation.
Then you multiply them and realise you've been quoting an availability target that the architecture can't actually deliver, and that nobody along the way did anything wrong.
If you've got a good way of tracking external dependencies as they get added, I'd like to hear it. Ours is mostly discipline, which isn't a system. LinkedIn.