Your store went down and you did nothing wrong: BGP, fibre cuts, and shared infrastructure

Somewhere between checking your order dashboard and refilling your coffee, your store disappeared. Not because you pushed a bad theme update or forgot to renew a domain. Somewhere between a data center in Virginia and the router in your customer's ISP, a piece of the internet's plumbing failed, and your store went down along with thousands of others that had nothing in common except that they all depended on the same upstream provider.

What actually happened in February 2026

In February 2026, Cloudflare withdrew a set of customer routes through BGP (Border Gateway Protocol), the system that tells internet traffic which path to take between networks. Around the same time, a fibre cut in eastern North America severed physical cable that a large amount of traffic depended on. Neither event was rare in isolation. BGP misconfigurations and fibre cuts happen with some regularity; most go unnoticed because redundant paths absorb the loss. This time, the combination was large enough that people outside the networking world noticed, because their stores, apps, and banking portals stopped responding at the same time.

None of this was caused by a store owner's code, plugin, or theme. It was caused by the shared infrastructure that almost every online store, regardless of platform, ultimately depends on: a small number of CDNs, DNS providers, and backbone carriers that route a disproportionate share of global traffic. When one of them stumbles, the outage doesn't respect platform boundaries. Shopify, WooCommerce, and BigCommerce stores all went dark in the same window, because the fault sat below all three.

Why this keeps happening, and why it isn't going away

The internet was designed to be decentralized, but the economics of running it have concentrated a lot of critical function into a small number of providers. Most stores route DNS, CDN, and DDoS protection through one of a handful of companies because it's cheaper and more reliable than doing it themselves; that's a reasonable trade most of the time. The tradeoff is that when one of those providers has a bad day, correlated failures ripple across an enormous number of unrelated businesses at once.

Cloudflare has published postmortems after previous incidents explaining, in detail, how a configuration change propagated faster than the systems meant to catch it. That kind of transparency is useful, but it doesn't change the underlying fact: a fibre cut from a construction crew, a bad BGP announcement from a network hundreds of miles away, or a routing table update at an internet exchange can all take your storefront offline, and there is very little a small or mid-size store operator can do to prevent any of it directly.

The question that actually matters: detection, not blame

When something like this happens, the instinct is to figure out whose fault it was. That's understandable, but it's the wrong first question if you're trying to protect revenue and trust. The better questions are: how long was my store down before I knew, what did my customers see when they tried to check out, and did I say anything to them before they gave up and left.

A store that goes down for eleven minutes and sends a calm status update to its email list looks more competent than one that goes down for four minutes and says nothing, because customers judge you by what they experience, not by the root cause. The real cost of an hour of downtime isn't just the lost sales during the outage; it's the abandoned carts and lowered trust that follow it if customers hit a blank page with no explanation.

This is where continuous, external ecommerce uptime monitoring earns its keep. A monitoring system that checks your storefront from outside your own infrastructure, on a schedule measured in minutes rather than hours, is what turns a silent outage into a known, timed, and communicated event. Without that, you often find out about downtime the same way your customers do: by trying to buy something and failing.

Is it my store, or is it the road to my store?

One of the most useful distinctions in outage response is separating an origin failure (your server, your app, your database) from a path failure (DNS, CDN, backbone routing, an upstream provider). They look identical from a customer's browser: a spinning wheel, a timeout, a blank white page. But they require different responses.

If your origin is down, you might need to roll back a recent theme update or check a plugin conflict. If the problem is upstream, in the DNS resolver, the CDN edge, or the fibre between two internet exchanges, there is often nothing to fix on your end at all; you wait for the provider to resolve it and you communicate clearly in the meantime. Monitoring that checks from multiple external locations, rather than a single ping from one server, helps you tell these apart quickly. If your store is unreachable from three regions but reachable from a fourth, that's a routing problem, not a code problem, and it changes what you do next: you stop debugging your own stack and start checking provider status pages.

This distinction also matters for smaller, more common outages that get mistaken for big infrastructure events. A lapsed domain renewal produces the same blank-page symptom as a fibre cut. So does a broken sitemap confusing search crawlers into thinking your site is gone, though that shows up as a traffic drop rather than a hard outage. Knowing which failure mode you're looking at is the difference between a five-minute fix and a five-hour wild goose chase.

What you can actually control

You can't prevent a fibre cut or a BGP misconfiguration at a provider you don't control. What you can control is how fast you know, and how you respond while it lasts.

First, monitor from outside your own stack. A dashboard that only tells you your server's CPU is fine won't catch a DNS or CDN failure between your customers and your storefront. External, multi-region checks catch what internal metrics miss.

Second, have a communication plan ready before you need it, not during the outage. A short, prewritten status-page template and a social post you can adapt in sixty seconds beats composing an apology from scratch while customers are already emailing you.

Third, know your alerting channels well enough that you'll actually see the alert. An email buried in a folder you check twice a day isn't monitoring, it's a diary entry. If you run a Shopify store, see how to monitor a Shopify store for a rundown of what to watch and how often. WooCommerce owners face a similar challenge across more layers; how to monitor a WooCommerce store walks through where those layers tend to fail.

This is the layer where a service like Cassian™ fits: continuous, external checks that watch your storefront the way a customer would encounter it, and alert you the moment something breaks, whether that something is your own code or the internet's plumbing underneath it. The Cassian Score™ gives you a single number to glance at rather than a dozen dashboards, and Cassian keeps monitoring afterward, not just at the moment of failure.

The bottom line

Store downtime causes range from a bad plugin update to a fibre cut three states away, and increasingly the second category is the one making headlines. You won't stop a BGP route withdrawal or a construction crew hitting a cable. What you can do is shorten the gap between the moment your store goes dark and the moment you know it, and use that time to keep customers informed rather than confused. That gap, not the root cause, is what determines whether an outage becomes a footnote or a dent in trust.