ThousandEyes recorded 509 global network outage events during the week of July 6 through July 12, 2026 — spanning ISPs, cloud service provider networks, collaboration app networks, and edge networks — a 15% jump from the 443 outages logged the week before. Buried inside that aggregate number are three incidents worth pulling out individually: a 51-minute disruption at Arelion (formerly Telia Carrier) on July 2 that touched customers in dozens of countries, a 38-minute outage centered on Comcast's Chicago nodes on July 9, and a 9-minute event at transit provider Unitas Global / PacketFabric on July 11 that reached across nine countries in a matter of seconds. None of these were cloud outages in the sense most disaster-recovery plans mean the term. None of them involved AWS, Azure, or Google Cloud losing a region. They were backbone and transit-provider failures — and they deserve a different kind of attention than the cloud-region incidents that usually dominate the post-mortem conversation.
A different failure category than the one your runbook probably covers
Most enterprise disaster-recovery planning over the last decade has organized itself around a specific mental model: what happens if our cloud provider's region goes down. That model produced real, useful architecture — multi-AZ deployments, cross-region failover, the kind of thinking this blog covered when a cooling failure in a single Northern Virginia availability zone took down AWS's us-east-1 region for the better part of a day. But a Tier 1 backbone provider or transit network going down is a structurally different event. Arelion is one of a small number of Tier 1 networks that carry a meaningful share of global internet backbone traffic without paying anyone else for transit — they sit at the top of the internet's settlement-free peering hierarchy. When a network at that layer has a bad day, the effect isn't confined to customers who happen to run workloads on Arelion's infrastructure. It ripples into every downstream ISP, enterprise network, and cloud provider whose traffic happens to transit through Arelion's routes at that moment — regardless of whether those organizations have ever heard of Arelion, much less signed a contract with it.
That's the part conventional DR planning misses. You can be multi-cloud, multi-region, and fully redundant at the compute layer, and still have every one of those redundant paths converge on the same handful of backbone providers a few hops upstream. Your AWS us-east-1 deployment and your Azure East US 2 deployment might both be reachable from your office in perfectly normal conditions and both become unreachable at the same moment if the transit path connecting your network to the internet's core degrades. The redundancy you built protects against the failure mode you modeled. It does nothing for the failure mode sitting one layer below your architecture diagram, in infrastructure you don't operate, can't see into, and in most cases have never audited.
Why the Arelion, Comcast, and PacketFabric incidents matter more than their outage durations suggest
Read purely by duration, none of last week's three flagship incidents sound dramatic. Fifty-one minutes, thirty-eight minutes, nine minutes — compared to a us-east-1 event that took the better part of a day to fully resolve, these look like footnotes. But duration is the wrong metric for backbone and transit outages, because the metric that actually matters is blast radius per minute. The Arelion outage reached customers and downstream partners in the US, UK, Canada, Germany, Japan, Australia, and dozens of other countries in under an hour. The PacketFabric incident hit customers across the US, the Netherlands, Malaysia, Taiwan, Ireland, India, Canada, Italy, and Singapore in nine minutes — faster than most incident response teams can even convene a bridge call, let alone diagnose root cause. Comcast's Chicago-centered event lasted 38 minutes but was long enough to disrupt partner and customer traffic across the US and Canada during a normal Thursday.
Compare that geographic spread to the AWS CloudFront/VPC Origins incident this blog covered earlier this year, where the blast radius, while significant, was still bounded by which customers used that specific AWS service configuration. A Tier 1 backbone incident doesn't respect service boundaries, vendor boundaries, or customer relationships. It respects only the physical and logical topology of the internet — and because a relatively small number of Tier 1 and major transit providers carry a disproportionate share of global traffic, a bad 10 minutes at any one of them can outrank a bad 10 hours at a single cloud vendor in terms of how many organizations feel it simultaneously.
The 15% week-over-week jump is a trend, not a blip
A single volatile week of outage counts wouldn't be worth writing about on its own — network monitoring data is naturally noisy, and week-over-week swings happen for reasons as mundane as monitoring coverage changes or reporting methodology. But a sustained pattern of rising outage volume, layered on top of individually notable incidents at Tier 1 and transit-layer providers, is a signal worth taking seriously rather than dismissing as statistical noise. Several structural forces point in the same direction. Internet routing paths have grown steadily more complex and more interdependent over the past several years, as content delivery networks, cloud interconnects, and direct peering arrangements multiply the number of paths traffic can take — and the number of places a single misconfiguration or hardware failure can cascade. A meaningful share of the core routing and transport infrastructure carrying global traffic today was built years ago and is now absorbing traffic volumes, connection counts, and topological complexity well beyond what it was originally sized for. And the traffic itself keeps growing: video, real-time collaboration, and increasingly AI-driven inference and training traffic are all adding load to networks that were provisioned for a different era's usage patterns.
None of these forces are going to reverse course on their own. If anything, the AI-driven traffic growth piece is likely to accelerate demand on exactly the backbone and transit capacity that failed last week, at exactly the moment when that capacity is already showing signs of strain. Treating a 15% week-over-week increase in outage volume as noise is a defensible read of any single data point. Treating a multi-week trend of rising outage counts, combined with individually significant Tier 1 incidents, as noise is a choice that gets harder to justify the longer the pattern holds.
Why "which cloud region are we in" is the wrong first question
Ask most infrastructure teams what their biggest single point of failure is, and you'll get an answer framed entirely around compute: a specific AWS region, a specific data center, a specific Kubernetes cluster. Very few teams can answer a parallel question with the same confidence: which transit providers carry our traffic between our network and our cloud provider's network, and what happens if one of them has a bad day. That's not because the question doesn't matter — the Arelion, Comcast, and PacketFabric incidents last week are proof that it does — it's because the answer usually isn't visible from inside a standard cloud console. Your cloud provider's status page will tell you if their region is degraded. It will not tell you if the transit path between your office, your data center, or your end users and that region is degraded, because that path is often outside your cloud vendor's operational control entirely.
This is also where incident triage gets genuinely difficult without the right tooling. When an application becomes unreachable, the instinctive first move is to check whether the application itself, or its hosting infrastructure, is down. If the app's compute and storage are healthy and the cloud provider's status page is green, teams can burn twenty or thirty minutes chasing application-layer theories — a bad deploy, a database lock, a certificate expiry — before anyone considers that the actual fault lies in the network path several hops upstream, in infrastructure neither the application team nor the cloud vendor controls.
Building a network resilience posture that assumes the path will fail, not just the endpoint
The practical response to this class of risk looks different from the multi-region cloud playbook, because the failure domain is different. A few concrete moves are worth prioritizing:
- Treat single-transit-provider dependency as a single point of failure, even if your compute is multi-region. Multi-region compute redundancy protects nothing if all regions are reachable only through one upstream transit provider. Work with your network team or ISP to confirm actual path diversity, not just contractual diversity — two circuits from the same underlying carrier don't count.
- Deploy continuous, path-level network monitoring, not just endpoint uptime checks. Tools like ThousandEyes, Kentik, and Catchpoint exist specifically to make the transit layer visible — tracing the actual route traffic takes between your users, your offices, and your cloud or SaaS providers, and flagging degradation in that path before it becomes a full outage.
- Build alerting that can distinguish "our application is down" from "the network path to our application is down." These require different responders, different remediation, and different customer communication. Collapsing them into a single generic "service degraded" alert slows down triage exactly when speed matters most.
- Extend vendor risk questionnaires past your cloud provider to your network providers. Ask every critical SaaS and infrastructure vendor which transit and backbone providers carry their traffic, and whether they've documented a plan for a Tier 1 outage rather than only a cloud-region outage.
- Run a tabletop exercise specifically for a transit-layer failure, separate from your cloud-region failover drill. If your last DR test only simulated "AWS region unavailable," you have not tested what happens when your network path to every region, cloud, and SaaS vendor degrades simultaneously for reasons entirely outside any of their control.
None of this requires abandoning the multi-region and multi-cloud architecture work most teams have already invested in — it requires extending that same resilience thinking one layer down, to the part of the stack that carries traffic between your infrastructure and everyone else's.
Last week's 509 outages, and the specific incidents at Arelion, Comcast, and PacketFabric inside that count, are not going to make headlines the way a full-day AWS regional outage does. They're smaller, shorter, and less visible to end users who never notice a 9-minute routing hiccup on the other side of the world. But they're arguably a better predictor of what actually threatens most organizations' uptime day to day, because they happen more often, they happen regardless of which cloud vendor you chose, and most DR plans still don't have a line item for them. The organizations that come out ahead over the next few years won't be the ones with the most redundant compute — plenty of teams already have that. They'll be the ones who extended their resilience thinking to the transit path connecting all of that redundant compute to the rest of the internet.