Your work app will not let you sign in. Another website will not load properly. A service you open to check what is happening also seems stuck.
It is reasonable to suspect your connection. But sometimes the services share a problem somewhere you cannot see: a company they all rely on, or a system used by their suppliers.
Different brands do not necessarily mean independent infrastructure. That hidden connection helps explain how a single fault can interrupt several otherwise unrelated services. It also changes what counts as a useful backup.
Three suppliers can share the same machinery
Imagine a small retailer that buys its storefront, customer-support chat and staff scheduling software from three companies. This is an illustrative example, not a report about particular products.
Each supplier may rent computing or storage, use another service to check logins, and rely on a network to deliver content. Two suppliers could make the same choice. A third could depend on a company that uses that same infrastructure further down the chain.
The retailer sees three bills and three support teams. The underlying map may contain a shared point of failure.
The effect depends on what that component does. Losing a recommendation feature might leave shopping available. Losing a required login service might prevent customers from entering at all. Microsoft’s failure-analysis guidance makes this distinction: some dependencies are essential to a task, while others affect only particular features.
Why companies buy the same building blocks
Building every piece yourself has a price. Servers need space and power. Capacity has to be available before a busy period. People have to maintain the systems, including when customers are asleep.
Cloud providers sell a way to share that work. AWS’s explanation of cloud economics highlights lower upfront infrastructure spending, capacity that can change with demand, and the economies of serving many customers. Those are the provider’s stated benefits, rather than a guarantee that every cloud bill will be cheaper.
For a small software company, buying an established service can make a product possible sooner. Its developers can spend more time on the feature customers actually came for. A specialist may also operate infrastructure more reliably than that small team could manage alone.
The trade-off appears across the wider market. When many businesses choose shared building blocks, a fault in one of those blocks can reach beyond any individual customer. A sensible purchasing decision can create a dependency that the final user never chose directly.
What one storage failure interrupted
Cloudflare’s June 12, 2025 outage provides a documented example. It lasted two hours and 28 minutes and affected a range of the company’s services. Its Workers KV storage service depended partly on a third-party cloud provider that suffered an outage.
KV was also used inside Cloudflare for tasks including configuration, authentication and asset delivery. The storage problem therefore spread into other products. Cloudflare reported that Access could not complete identity-based logins, while some other authentication methods remained available.
That is an important detail: a service can become inaccessible because it cannot verify permission, even when the thing someone wants to reach has not itself disappeared.
Cloudflare said the incident caused no data loss and was not an attack. Its DNS, cache, proxy and web application firewall services were not directly affected. Describing this as the whole internet going down would erase the distinctions that explain the incident. Cloudflare’s incident report
A second location is only part of the answer
Distance protects against some problems. Systems in different locations need not share the same power failure or damaged building. But they can still share software, a login dependency or a change distributed to both.
In its separate report on the June 12, 2025 Google Cloud incident, Google described a policy update containing blank fields that triggered crashes in its Service Control software. Policy data spread globally within seconds. Regional deployment alone did not contain that particular failure. Google Cloud’s incident report
The practical inference is that a backup needs independence from the failure you are trying to survive. Two apps using the same unavailable login route may offer little help with a login outage. Two copies of a service can still depend on one database.
AWS makes a related warning in its multi-location reliability guidance: dependencies between regions can weaken the protection that multiple regions were meant to provide. More locations also bring extra complexity and cost.
Redundancy takes work after you buy it
Cloudflare’s follow-up, published August 8, 2025, adds a revealing part of the story. Workers KV had previously used two outside storage providers. The company said consistency problems, different operating limits and maintenance overhead contributed to a temporary move to one provider while it developed its own infrastructure.
After the outage, restoring the old arrangement was not a quick switch: the infrastructure and code needed further work. Cloudflare subsequently reported storing all KV data on its own infrastructure and serving requests from it alongside third-party infrastructure used for redundancy. Cloudflare’s redesign explanation
The lesson is about ongoing maintenance. Paying for a second provider does not establish that it can take over, has the right data, or can handle the demand. The alternative has to remain usable as the main system changes.
That is also why a small business should start with the tasks it cannot afford to lose, rather than buying an elaborate second copy of everything.
A small plan for the next interruption
You cannot audit the entire supply chain behind every app. You can identify the parts of your day that need a fallback.
Keep essential information available without a fresh login. Think about today’s itinerary, a presentation or the contact details needed to explain a delay. Google’s offline-file guidance describes preparing supported files in advance. Check that the actual files open on the device you will carry, and protect sensitive copies appropriately.
Ask what still works when a supplier fails. If you run a business, ask your software provider which critical outside services it uses and what happens when one is unavailable. A useful answer describes a task, such as taking bookings, and the fallback for it. An impressive list of data centres answers a different question.
Keep a way to communicate outside the broken workflow. Your only support instructions should not be inside the app that staff cannot open. Google’s 2025 report noted that its own service-health infrastructure was affected, delaying its first incident report. Even the route used to explain a problem can share the problem.
Test one realistic interruption. Choose an ordinary task and ask whether the proposed alternative actually completes it. A saved phone number or readable local file can be more useful than another subscription nobody has tried.
When the next cluster of errors appears, check the services’ official status information before making disruptive changes to your own setup. Shared symptoms are a clue to investigate, not proof of a particular cause.
The important question is simple: if this part stops working, what else stops with it? A backup becomes valuable when you can answer that question and still complete the task that matters.
_027.png){kind=link}