Cloudflare just published its Q2 2026 Internet Disruption Summary, and the biggest lesson for on-call engineers is uncomfortable: most of the outages that ruin your week are not caused by your own code. Third party outages, upstream provider failures, cable cuts, DNS misconfigurations, and government shutdowns all produce the exact same symptom your users care about, which is that your product stops working. This post breaks down what the report found, why these external failures are so hard for on-call teams, and how to build a practical incident response playbook for outages you do not own. If you run production systems, the payoff is a calmer, faster response the next time something outside your stack takes you down.
The data covers April through June 2026, drawn from Cloudflare Radar traffic measurements across the global internet. It reads less like a list of software bugs and more like a weather and geopolitics report. Typhoons, earthquakes, drone strikes, exam season, and a single bad cryptographic key all show up as sharp drops in traffic. For anyone who carries a pager, that is the point worth sitting with: the failure domain that hurts your customers extends far beyond the boundary of the code you wrote and the servers you manage.
The headline shift from the previous quarter is about cause. Q1 2026 was dominated by power failures. Q2 2026 flipped to deliberate, government directed shutdowns. When you add up the exam season blackouts, government mandated outages accounted for roughly 56 percent of all tracked events. That is not a rounding error. It means the single most common reason large groups of users lost connectivity last quarter had nothing to do with any provider's reliability engineering at all.
The specific incidents paint the picture better than the percentages. Iran began restoring nationwide access on May 26 after an 88 day shutdown that started on February 28, with traffic climbing back to roughly 59 percent of pre shutdown levels rather than fully normalizing. Iraq ordered three government mandated blackouts in June, each lasting about 90 minutes and timed to exam windows. Sudan ordered ten separate shutdowns between April 13 and 23, each running about 3.5 hours, again to stop students from cheating on exams. These are scheduled, predictable, and completely outside the control of any engineering team whose users happen to live in those regions.
The most instructive incident in the whole report for on-call engineers is the DENIC event. On May 5, a routine cryptographic key rollover at DENIC, the registry that runs Germany's .de domain, went wrong and started producing invalid DNSSEC signatures. Every resolver that validates DNSSEC rejected every .de lookup for several hours until the registry corrected it. The network itself was healthy the entire time. Packets flowed. Servers were up. And yet, from a user's chair, .de websites simply stopped loading, email bounced, and apps timed out. As Cloudflare's Lai Yi Ohlsen put it, the incident "was experienced not as a DNS or cryptographic failure but simply as a wave of .de websites and services suddenly becoming unreachable."
Sit with that for a second, because it is the crux of modern on-call. A dependency you did not build, running a protocol you probably do not monitor closely, changed one key and made your product look broken to a whole country. Your dashboards would show green. Your synthetic checks from inside your own cloud region might pass. Your users would be filing tickets and tweeting that you are down. This is the failure mode that separates a mature incident response process from a panicked one.
The report is full of reminders that infrastructure is made of atoms. Damage to physical infrastructure in the United Arab Emirates and Bahrain kept traffic to an AWS cloud region in the UAE depressed since March, after drone strikes hit two facilities in the UAE and a strike near a Bahrain facility caused physical damage. Cloudflare was careful to note that the lower traffic "is the downstream signature of physical damage to the underlying data center infrastructure rather than a network fault, and it continues to affect the websites and applications hosted in that region, regardless of their own availability."
Elsewhere, a fiber cut near Saint Lucia on June 21 dropped Karib Cable's network to near zero and pulled the whole country's traffic down about 60 percent for nearly a day. Super Typhoon Sinlaku passed just north of Guam in mid April and knocked territory traffic down as much as 80 percent below expected levels through power and water damage. Two earthquakes struck northern Venezuela within about a minute of each other on June 24, and Cloudflare Radar caught the exact moment traffic collapsed across multiple ISPs. A power outage in Tanzania on June 27 cut traffic for at least five hours, with a telemetry footprint nearly identical to a deliberate election related shutdown from the year before. Different root causes, same shape in the data, same experience for users.
Software teams spend enormous effort making their own services reliable. We write runbooks for our databases, we load test our services, we chaos test our own failure modes. What we under invest in is the response to failures we cannot fix. Third party outages are uniquely painful for a few structural reasons.
First, they defeat your instinct to fix. On-call engineers are wired to dig into logs, find the bad deploy, and roll it back. When the root cause is a registry in another country or a severed fiber under the Caribbean, there is no rollback. The muscle memory that usually resolves incidents becomes wasted motion, and worse, it delays the response that actually helps, which is communication and mitigation.
Second, they scramble your signal. Your own observability is built to watch your own systems. A DNSSEC failure at a TLD registry, a BGP route leak at an upstream transit provider, or a regional cloud problem may not trip a single one of your internal alerts, because every component you own is behaving correctly. You find out from users, from social media, or from a status page you were not watching. That detection gap is where minutes turn into hours.
Third, they cross team boundaries. An external outage often hits payments, auth, email delivery, and your CDN all at once because they share an upstream you never mapped. Suddenly three on-call rotations are paged for what looks like three separate incidents that are actually one. Without a fast way to connect those responders in a single place, you get duplicated effort, conflicting customer messaging, and a fractured timeline.
Fourth, the clock is louder. When you cannot fix the root cause, every minute is spent purely on blast radius: how many users, which regions, what workarounds, and what you tell customers. The value of your response shifts almost entirely from engineering to coordination and communication, which is precisely the part most teams have practiced least.
The good news is that external outages are learnable. You cannot prevent a typhoon or a bad key rollover, but you can build a response that turns chaos into a practiced routine. Here is how to structure it.
Your first job in any incident is to answer one question quickly: is this our fault or someone else's? That answer routes everything that follows. Invest in external signals, not just internal ones. Run synthetic checks from outside your own cloud, ideally from multiple regions and multiple networks, so a regional cloud problem or a DNS failure shows up as a real red check rather than a mystery. Watch your critical dependencies directly. If you rely on a specific DNS provider, payment processor, email relay, or CDN, subscribe to their status feeds and pull them into the same alerting pipeline you use for your own services. When users in one country report failures but your internal metrics are green, treat that divergence itself as a high signal alert, because it usually means the problem lives upstream.
You cannot reason about an external outage if you do not know what you depend on. Maintain a dependency map that lists your critical third parties, what each one does for you, what breaks if it goes down, and what the fallback is. This does not need to be a fancy tool. A well maintained page with your DNS providers, TLD registrars, cloud regions, CDN, auth provider, payment processor, and messaging vendors, each with a known status URL and a named internal owner, will save you fifteen frantic minutes in the middle of an incident. When the pager goes off and someone says "email is bouncing," the map lets you jump straight to "our relay provider is having a regional issue" instead of tearing apart your own mail code.
When you cannot fix the root cause, honest and fast communication is the single most valuable thing you can deliver. During the DENIC incident, the companies that fared best with their users were not the ones who fixed .de DNSSEC, because none of them could. They were the ones who quickly told customers "we are aware of an upstream DNS issue affecting some regions, here is what we know, here is the workaround, here is when we will update next." Decide in advance who owns customer messaging during an incident, where updates go, and how often you will refresh them even when there is nothing new to report. A status page that updates every 30 minutes during a multi hour external outage buys more goodwill than any engineering heroics.
Here are the core practices worth committing to before your next external outage, not during it:
Because external outages fan out across payments, auth, email, and delivery at once, the response has to converge even when the alerts diverge. The teams that handle these well have a single, low friction way to pull every affected responder into one conversation, attach the timeline, and keep customer messaging consistent. The failure pattern to avoid is three separate rooms arguing about three symptoms of one upstream cause while customers get three different explanations.
This is where the tooling you choose quietly determines how your incidents feel. Most engineering teams already live in Slack, so the response that works is the response that happens where people already are. A Slack-native on-call and incident management tool like Pagerly is built around exactly this reality. On-call schedules, escalations, and alerts live inside Slack, which means when an upstream provider fails at 2am, the page arrives in the channel your responders already watch, and acknowledging or escalating is one click rather than a context switch into a separate app.
For the messy, cross team nature of third party outages, the practical wins are concrete. You can spin up an incident channel and pull the right on-call people from multiple rotations into one place immediately, so the payments, auth, and platform responders who all got paged for the same upstream failure end up in a single timeline instead of three. Because the schedule and escalation policy are native to Slack, there is no ambiguity about who is on point, and overrides or swaps for a long running external incident take seconds. When the root cause is not yours to fix, keeping a clean, timestamped record of what you saw, when you posted to your status page, and what you told customers is most of the value, and having that assembled automatically in the channel you already work in means your post incident review starts from facts rather than memory.
None of this fixes a severed fiber or a registry's key rollover. What it does is remove the coordination tax that makes external outages feel worse than they are, so your team spends its energy on blast radius and customer communication instead of fighting the tools while the clock runs.
To make this concrete, here is a lightweight sequence you can adapt. Treat it as a starting template and shape it to your stack.
Step one, confirm scope. When an alert or a wave of user reports comes in, immediately check whether your own systems are healthy. If internal metrics are green but external checks or user reports are red, raise the hypothesis that this is upstream and move to your dependency map.
Step two, identify the dependency. Match the symptom to your map. Email bouncing points at your relay or DNS. A whole region failing points at a cloud region or a transit provider. One country failing points at a government action or a local ISP. Pull up that provider's status page and confirm.
Step three, declare and converge. Open one incident channel, page the incident commander, and pull in every rotation touched by the dependency. Resist the urge to run parallel investigations. One incident, one timeline, one owner.
Step four, mitigate what you can. You cannot fix their problem, but you may be able to fail over to a secondary provider, serve a degraded but functional experience, cache more aggressively, or reroute traffic away from the affected region. Decide fast whether a mitigation is worth the risk of adding a second moving part during an incident.
Step five, communicate on a cadence. Post to your status page early, describe the impact honestly, name the workaround if there is one, and commit to a next update time. Keep that promise even when there is nothing new. Silence during an external outage reads as incompetence even when your team is doing everything right.
Step six, review blamelessly. When it is over, run a postmortem that treats the external cause as a fact of life and focuses on your own detection speed, your communication timeliness, and whether your dependency map and failover options were good enough. The registry's mistake is not your action item. Your five hours of silence would be.
The clearest message from Cloudflare's Q2 2026 data is that the internet fails for reasons that have nothing to do with your code, and it fails often. Storms, quakes, drone strikes, cable cuts, exam schedules, and a single mistyped cryptographic key all produced the same thing your users experienced as your product being down. You cannot stop any of those. What you can control is whether your on-call response to them is a practiced routine or a scramble.
Mature teams accept that a meaningful share of their incidents will originate outside their walls, and they build for it deliberately. They detect from the outside, they map their dependencies, they pre assign roles, they converge fast, and they communicate on a clock. The tooling that makes this natural, on-call and incident response that lives in the same place your team already works, is not a luxury during an upstream outage. It is the difference between a calm, well documented hour and a chaotic, finger pointing afternoon. The next external outage is already scheduled somewhere in the world. The only open question is how ready your team will be when its footprint shows up in your traffic.
