Most of the outages that will page your team this quarter did not start in your code. They started in the physical world: a storm, a severed fiber cable, a data center losing power, or a government flipping a national switch. That is the uncomfortable takeaway from Cloudflare's Q2 2026 Internet Disruption Summary, published on July 29, and it has real consequences for how on-call teams practice incident response. When the root cause sits outside your infrastructure, the usual instinct to find the bad deploy and roll it back does not help. You still have to detect the problem, coordinate a response, and keep customers informed, all while the thing that is actually broken is somewhere you cannot reach.
The report, built on Cloudflare Radar traffic data from April through June 2026, reads less like a software changelog and more like a weather and geopolitics briefing. Typhoons, earthquakes, undersea cable cuts, blackouts, DNSSEC key rollovers gone wrong, and deliberate national shutdowns all left their mark on global internet traffic. For anyone who carries a pager, it is a useful reminder that reliability is a shared, physical, and often fragile thing. Below we walk through what the report found, why external outages are some of the hardest incidents to run, and a practical playbook for responding when you cannot fix the root cause yourself.
Cloudflare's summary groups the quarter's disruptions into a few recurring causes. What stands out is how rarely a classic software bug appears. Instead, the internet kept breaking because of the world around it, and the failures often looked identical to one another from a user's seat even when the underlying causes were completely different.
The single largest event was national. Iran began restoring nationwide internet access on May 26, ending an 88 day shutdown that had started on February 28. Traffic reached 40% of pre shutdown levels the day after restoration, climbed as high as 90%, then settled back to roughly 59%. As Cloudflare's Lai Yi Ohlsen put it, that volume was consistent with earlier baselines, suggesting connectivity had returned to something like its most recent normal rather than fully recovering.
Exam season brought a familiar pattern of smaller, deliberate blackouts. Iraq ordered three government mandated shutdowns on June 2, 11, and 28, each lasting around 90 minutes. Sudan ordered ten shutdowns between April 13 and 23, running about 3.5 hours each, all timed to exam windows and intended to stop students from cheating. None of these were technical failures at all, yet to any application depending on users in those regions, they were indistinguishable from a total loss of availability.
Two Q2 events show how a single control plane mistake can mimic a network outage. On May 5, a routine cryptographic key rollover at DENIC, the registry for Germany's .de domain, went wrong and started producing invalid DNSSEC signatures. Resolvers that validate DNSSEC rejected every .de lookup for several hours until the registry fixed it. Users saw pages fail to load and email bounce, the exact symptoms of an outage, even though the network itself worked the entire time. As Ohlsen noted, the incident "was experienced not as a DNS or cryptographic failure but simply as a wave of .de websites and services suddenly becoming unreachable."
Physical damage did the same thing elsewhere. In the Caribbean, a fiber cut near Saint Lucia dropped Karib Cable's network close to zero traffic on June 21, and service stayed disrupted for nearly a day. Because Karib Cable is one of the island's largest providers, the country's overall traffic fell by about 60% versus the prior week. Damage to physical infrastructure in the United Arab Emirates and Bahrain has also kept traffic to an AWS cloud region in the UAE low since March, after drone strikes hit two facilities in the UAE and another strike caused damage near a Bahrain facility. Cloudflare described the reduced traffic as "the downstream signature of physical damage to the underlying data center infrastructure rather than a network fault," a failure that continues to affect hosted applications regardless of their own health.
Weather and seismic events rounded out the quarter. Super Typhoon Sinlaku, the strongest Pacific storm of the 2026 season so far, passed just north of Guam in mid April. The island avoided a direct hit, but tropical storm force winds still knocked out power and water, and traffic from the territory dropped as much as 80% below expected levels on April 13 and 14. On June 24, two earthquakes struck northern Venezuela within about a minute of each other, the first measuring magnitude 7.5, and Cloudflare Radar recorded a sharp drop in HTTP traffic across multiple providers at the moment of the quakes. A power outage in Tanzania on June 27 then cut HTTP traffic for at least five hours.
The Tanzania case captures the report's central lesson. Cloudflare noted that the June power outage telemetry looked almost identical to a deliberate, election related shutdown the country imposed in October 2025, even though the two events had entirely different causes. "It is striking how such fundamentally different events leave such similar footprints in the data and user experience," Ohlsen concluded, pointing to "the importance of Internet resilience and of building networks with enough redundancy in power, routing, and physical paths to withstand inevitable shocks."
On paper, an outage you did not cause sounds easier. There is no frantic hunt for a bad commit, no rollback under pressure. In practice, external and third party failures are often the messiest incidents an on-call engineer will face, for three reasons.
First, there is nothing to fix. Your normal remediation muscle memory, ship a patch, revert a deploy, scale a service, is useless when the fault lives in a fiber line under the sea or in a DNS registry in another country. The response shifts from "repair" to "detect, mitigate, and communicate," which many teams practice far less.
Second, ownership is ambiguous. When a dependency degrades, the first ten minutes are usually spent arguing about whether the problem is even yours. Is the database slow, or is the cloud region degraded? Is our API down, or is a customer's ISP dropping traffic? That ambiguity burns the most valuable minutes of any incident, the early ones, when a clear signal would let you act.
Third, the communication load is enormous. Customers do not care that the root cause is a typhoon near Guam or an invalid DNSSEC signature at a national registry. They care that your product is not working. Someone has to translate a murky, external, still developing situation into honest, timely updates, and to keep doing it while the underlying cause remains outside your control for hours.
The most quietly alarming thread in Cloudflare's report is how often different causes produce the same footprint. A DNSSEC misconfiguration, a fiber cut, a blackout, and a deliberate government shutdown can all show up as the same shape: traffic falling off a cliff, requests timing out, users unable to reach you. If your monitoring only tells you that "traffic dropped," you cannot tell a five hour power outage from a state ordered blackout, and you will waste the incident chasing the wrong hypothesis.
Good detection is not just about noticing that something is wrong. It is about narrowing the space of possible causes quickly. That means instrumenting the boundaries of your system, not just its core. Track error rates and latency per upstream dependency, per cloud region, and per major ISP or geography where you have meaningful traffic. When a spike is concentrated in one region or one provider, that pattern is itself a diagnosis. A drop that maps cleanly to a single country points at connectivity or policy, not at your last release.
Pair your own telemetry with external context. Public sources like Cloudflare Radar, provider status pages, and internet health trackers exist precisely so you can confirm, within minutes, whether an anomaly is yours or the internet's. The teams that respond fastest to third party outages are the ones who have wired that external context into the same place they triage everything else, so an on-call engineer does not have to go hunting across a dozen browser tabs while the clock runs.
Once you have accepted that the fault is external, the goal changes. You are no longer racing to a fix. You are racing to contain user impact, coordinate cleanly, and communicate honestly until the outside world recovers. That is a discipline, and it rewards teams that have practiced it.
The instinct to wait until you "understand it" before declaring an incident is exactly backwards for external outages, because you may never fully understand it in the moment. Declare early, open a single coordination space, and pull the right people in immediately. Fragmented response, three side conversations in three channels plus a couple of direct messages, is how facts get lost and duplicate work happens. A single, timestamped thread where every observation, decision, and customer update lives is worth more than any clever dashboard when you are reconstructing what happened later.
It is tempting to skip the formal structure when there is "nothing to fix," but roles matter more here, not less. Name an incident commander to own decisions and pacing. Name a communications lead to own customer and internal updates. Name someone to own the external investigation, watching provider status pages and traffic data for signs of recovery. Without explicit ownership, everyone assumes someone else is writing the status update, and no one is.
External outages are a test of communication maturity. You cannot promise a fix time you do not control, so do not. Say what you know, say what you are doing to reduce impact, and say when you will update next. "We are seeing degraded connectivity for users routed through an affected provider, we have failed over where possible, and we will update in 30 minutes" is honest and useful. Silence, or a vague "we are investigating" that never changes, erodes trust faster than the outage itself.
Pulling the threads together, here is a set of concrete practices that make external outages survivable. None of them require exotic tooling. They require deciding, before the incident, how you will respond when the cause is beyond your reach.
Most of this playbook comes down to speed and coordination, which is exactly where the response process either works or falls apart. This is the practical case for running on-call and incident response inside the tool your team already lives in. With a Slack-native platform like Pagerly, the alert that fires when traffic drops in a region reaches the right on-call engineer immediately, and the incident channel opens in the same place where the conversation is already happening. There is no context switch to a separate console at the worst possible moment.
Because escalation policies and schedules live alongside your channels, the ambiguity of "who owns this" shrinks. Pagerly pages the current on-call automatically, and if that person cannot confirm whether the fault is internal or external, escalation kicks in without anyone hunting for a phone number. Overrides and shift swaps are handled in Slack, so coverage stays clear even during a long, slow, physically caused incident that spans time zones and hours. Keeping the timeline, the decisions, and the customer updates in one threaded channel also means the postmortem writes half of itself, which matters when the lesson is subtle rather than a single bad deploy.
The point is not that a tool prevents typhoons or fiber cuts. Nothing does. The point is that when the cause is outside your control, the only variables you can still influence are how fast you detect, how cleanly you coordinate, and how honestly you communicate. Concentrating all three in the place your engineers already work removes friction from exactly the moments when friction is most expensive.
Cloudflare's closing note is the one worth pinning above your desk: build "networks with enough redundancy in power, routing, and physical paths to withstand inevitable shocks." The word inevitable is doing a lot of work there. Storms, quakes, cable cuts, and blackouts are not edge cases you can engineer away. They are a permanent feature of operating on a global, physical internet, and the Q2 2026 quarter was simply an ordinary sample of them.
Resilience, then, is less about preventing external failures and more about limiting their blast radius and shortening your reaction time. Architecturally, that means real redundancy: multiple regions, secondary DNS providers, diverse network paths, and graceful degradation so that losing one provider does not take everything with it. Operationally, it means treating third party and physical world outages as first class scenarios in your runbooks and game days, not as unlucky surprises. Run a drill where a whole cloud region "vanishes." Run one where DNS resolution fails for a top level domain. Practice the communication as deliberately as you practice the technical failover, because in an external outage, communication is most of the job.
It also means building the habit of blameless review even when the root cause was someone else's. The most valuable postmortems from external incidents rarely dwell on the provider. They ask sharper questions: did we detect it in two minutes or twenty, did our failover actually trigger, did customers hear from us before they complained, and did the on-call engineer have what they needed to act without paging half the company. Those are all things you control, and they are all things you can improve before the next disruption lands.
The steady lesson of Cloudflare's Q2 2026 report is that the internet is more physical and more fragile than our architecture diagrams suggest, and that wildly different causes can produce the same painful user experience. For on-call teams, that reframes the job. Reliability is not only about writing resilient code and avoiding bad deploys. It is about being ready to run a calm, coordinated, well communicated incident response when the fault is a typhoon, a fiber cut, a DNSSEC signature, or a national blackout, none of which you can fix and all of which are your problem the moment your users feel them.
You cannot control the weather, the geopolitics, or a distant registry's key rollover. You can control how quickly you notice, how cleanly you coordinate, and how honestly you keep people informed. Invest in those three, keep them in one place your team already trusts, and the next unexpected outage becomes a well run incident instead of a scramble. Given what Q2 2026 looked like, the next one is already on its way.
