Network outage incident response is the discipline nobody budgets time for until the week it becomes the only thing that matters. On August 21, 2026, Arelion, a global Tier 1 transit provider formerly known as Telia Carrier, went into an outage that touched customers and downstream partners in more than thirty countries at once, from the United States and Canada to India, Japan, Egypt, Brazil, Australia and most of Western Europe. No application deployed badly. No configuration changed in anyone's repository. The services people were trying to reach were, in the overwhelming majority of cases, running perfectly. The path between users and those services simply stopped working, in pieces, for a while, and then partly worked again, and then stopped again.

That pattern is the whole story, and it is why this class of incident deserves its own playbook. According to Cisco ThousandEyes data published in Network World's ongoing internet health report, the week of August 17 through August 23 saw 534 global network outage events across ISPs, cloud provider networks, collaboration app networks and edge networks. Public cloud network outages specifically rose from 162 to 189 globally, a 17 percent week over week increase, and in the United States they climbed from 143 to 174, a 22 percent jump. Those are not application failures. They are failures of the connective tissue that every application quietly depends on, and most on-call rotations are structurally unprepared to triage them.

What Actually Happened on the Backbone in Late August 2026

It helps to look closely at one incident rather than at aggregate numbers, because the shape of the failure is more instructive than the count.

The Arelion outage was a flapping, multi-city failure

The Arelion disruption was first observed at roughly 9:25 PM EDT on August 21 and cleared at approximately 12:35 AM EDT. Read those two timestamps and you get a three hour and ten minute window. Read the actual outage duration and you get one hour and twenty one minutes. The gap between those two figures is the entire problem.

The failure began on nodes in Chicago. About five minutes in, Atlanta nodes joined. Then conditions appeared to clear. Roughly five minutes after that apparent recovery, the Chicago nodes began failing again. Twenty minutes later Seattle joined. About an hour and twenty five minutes after the first observation, Chicago was joined by Dallas, San Jose, Sweden and the United Kingdom, and the count of affected downstream customers rose sharply at the same moment.

So the incident was not one outage. It was a sequence of partial outages separated by intervals of apparent health, spreading geographically as it went, with the worst blast radius arriving more than an hour after the first symptom. If your on-call process is built around the assumption that an incident starts bad and gets better, this failure mode will beat you twice: once when you declare an all-clear at the false recovery, and once when the real peak arrives after you have stood the response down.

The week's numbers put it in context

Total outage events that week were down 2 percent globally compared to the 546 of the prior week, which sounds reassuring until you break it apart. ISP outages dropped sharply, from 298 to 252 globally and from 169 to 148 in the United States. Public cloud network outages went the other way and rose 17 percent globally and 22 percent in the United States. The headline total was flat because two categories moved in opposite directions.

That divergence matters for on-call planning. A falling ISP number mostly affects end user reachability. A rising public cloud network number affects the paths between your services and the managed dependencies you cannot run without: object storage, managed databases, message brokers, identity providers, payment processors. The category that grew is the one that hits your architecture from the inside.

Why Network Outage Incident Response Is Different

Most incident runbooks are written for a failure inside a boundary the team controls. Network path failures violate three assumptions that those runbooks quietly rely on.

Nothing you own has changed

The first thing a competent responder does is check what changed. Deploys, feature flags, config pushes, schema migrations, scaling events. In a transit failure the answer is nothing, and that answer is destabilising. Teams typically respond by looking harder, which burns the first fifteen minutes of the incident on an investigation that cannot succeed. The correct move is to treat "no change on our side, symptoms are geographically clustered" as a positive signal that points outward, not as an absence of evidence.

The blast radius is asymmetric and confusing

When a backbone provider degrades, some users are fine and some are completely cut off, and which group a user falls into depends on their ISP, their region and which peering path their traffic happens to take. Your dashboards will show a partial error rate that looks like a capacity problem or a bad canary. Support will report a mix of "everything is broken" and "works fine for me" from customers on the same plan in the same country. Internally, half the engineering team can reach the admin panel and the other half cannot, which slows down the response itself.

Asymmetric reachability also breaks the instinct to reproduce. A responder who cannot reproduce the failure from their own laptop will tend to downgrade the severity. During a transit event that instinct is exactly backwards.

The failure flaps, and flapping punishes your process more than your systems

Systems mostly tolerate flapping. Retries, connection pools and circuit breakers absorb a good deal of it. Processes do not tolerate it at all. Every apparent recovery triggers a decision point: do we stand down, do we send the all-clear, do we release the incident commander, do we tell the customer it is resolved. Get that decision wrong once and you have to reassemble a response team that has already dispersed, usually at the exact moment the blast radius is expanding. Late night incidents make this worse, since the pull toward declaring victory and going back to sleep is strongest precisely when the flap window opens.

The Detection Problem: Why Your Monitoring Says Green

There is a structural reason network path failures show up late in most monitoring stacks, and it is worth being blunt about it.

Health checks that run inside your own network prove almost nothing

The typical health check is a request from a load balancer, a Kubernetes kubelet or an internal prober to a service in the same region, often in the same VPC. During an Arelion style transit event, every one of those checks passes, because none of them traverse the broken path. Your service genuinely is healthy. Your service is also genuinely unreachable for a fifth of your users. Both statements are true at once, and only one of them is on a dashboard.

The same applies to most uptime tooling that checks from a small number of vantage points. If your synthetic monitoring probes from three cities and none of them route through the affected transit provider, you will get a clean bill of health throughout the entire incident.

What to instrument instead

Detecting these events requires signals that live outside the failure domain or that measure the user's experience rather than the server's.

Client side success rate, segmented by geography and ASN. If your frontend or mobile client reports request outcomes back through a separate path, a regional collapse becomes visible in minutes rather than through support tickets. Segmenting by autonomous system number is what turns "some users are failing" into "users on these three networks are failing," which is an actionable statement.
External synthetics from many vantage points. Not three, and not all from the same cloud provider. The point is path diversity, so the probes need to sit on networks that fail independently of each other and of you.
Egress health toward critical dependencies. Measure and alert on your own success rate calling your managed database, object store, payment provider and identity provider, from each region you run in. This is the signal that catches the rising public cloud network outage category directly.
Connection level metrics, not just HTTP status. TCP retransmits, TLS handshake failures, connection timeouts and DNS resolution latency degrade before status codes do. They are the earliest honest indicator that a path is deteriorating.
Support and social volume as a first class alert source. A sudden spike in inbound reports is real telemetry. Route it into the same channel as your machine alerts instead of leaving it in a queue somebody reads hourly.

A Practical Network Outage Incident Response Playbook

Here is a sequence that works for path failures specifically. It is deliberately structured around confirming scope before chasing cause, because cause is usually not yours to find.

Minutes 0 to 10: establish that it is external, and say so out loud

Run three checks in parallel rather than in sequence. First, confirm your own services are healthy from inside: error rates at the application layer, saturation, recent deploys. Second, check reachability from outside your network using external vantage points, ideally from several different networks. Third, check whether the failure clusters by region, ISP or ASN.

If internal health is clean, external reachability is failing and the failures cluster geographically, declare it as a suspected network path incident inside the first ten minutes and state that explicitly in the incident channel. Naming the hypothesis early stops five engineers from independently auditing the last deploy. It is a cheap statement to retract if wrong and an expensive one to omit if right.

Minutes 10 to 25: map the blast radius before you write anything customer facing

You need three numbers before you communicate externally: what fraction of traffic is affected, which populations are affected, and whether the affected set is growing or shrinking. The Arelion pattern shows why the third number matters most. A team that measured only the first two at the thirty minute mark would have seen a modest, apparently recovering incident, and would have missed that the affected set nearly doubled an hour later.

Keep a running note of which regions and networks have joined the failure and when. That timeline is both your live decision input and, later, the spine of a postmortem that does not have to be reconstructed from memory.

Minutes 25 to 60: mitigate what you actually control

You cannot fix a Tier 1 provider's backbone. You can usually do several other things, and knowing in advance which of them are available to you is most of the value of having a playbook at all.

Shift traffic. If you run multi region or use a CDN with multiple origins, moving traffic away from the affected path is often possible in minutes. This only works if somebody has rehearsed the failover and knows where the control is.
Degrade deliberately. Turn off the non essential calls that are timing out and consuming connection pool capacity. A checkout that works without a recommendation widget is a far better outcome than a checkout that hangs waiting for one.
Adjust timeouts and retries with care. Long timeouts during a path failure convert a partial outage into a full one by exhausting workers. Aggressive retries convert it into a self inflicted load problem the moment connectivity returns. Both directions have failure modes, so make the change consciously rather than reflexively.
Communicate the asymmetry honestly. Tell customers that the issue is regional and connectivity related, that it may appear resolved intermittently, and when you will next update. Vagueness generates more inbound volume than bad news does.

The all-clear rule: earn it with time, not with a green check

Given a documented pattern of recovery followed by re-failure within five minutes, the single highest value process change available to most teams is a stability window before declaring resolution. Pick a duration that reflects your own history, commonly fifteen to thirty minutes of clean external signal, and hold the incident open until it elapses. Downgrade the severity if you like, release most of the responders, but keep one person assigned and keep the channel open.

This costs very little. Reassembling a dispersed response team at 1 AM costs a great deal. The asymmetry of those two costs is the entire argument.

Where Slack-Native On-Call Changes the Math

Every step above is a coordination problem more than a technical one. The signals are usually available somewhere. The difficulty is getting the right people looking at the same picture, quickly, at an hour when the alternative is nobody looking at all.

That is the specific case for running on-call where the conversation already happens. When paging, acknowledgement, escalation and the incident timeline all live in Slack, the person woken at 9:30 PM sees the alert, the recent history, who else is engaged and the running notes in one place, without opening a separate console and reconstructing context. Pagerly is built around exactly that: schedules, escalation policies, incident channels and timelines that live inside Slack rather than beside it.

Two capabilities matter disproportionately for flapping network incidents. The first is a durable incident timeline that captures each observation with a timestamp automatically, so the sequence of failures and partial recoveries survives the night and feeds the postmortem. The second is escalation that does not depend on one person staying awake and attentive through a three hour window with quiet stretches in the middle. If the primary responder goes quiet during a lull and the incident re-escalates, the policy should reach the next person without anyone having to notice first.

What to Change Before the Next One

Concrete items, in rough order of effort to value:

Add a stability window to your resolution criteria. One line in a runbook. It directly addresses the failure mode observed in the Arelion event and costs nothing to adopt.
Add "suspected external network path" as a named incident type. Give it its own short checklist. Naming a hypothesis is what stops a team from defaulting to a change audit that will find nothing.
Get one external, path-diverse synthetic check per critical user journey. Not per endpoint. Per journey, from networks that are not your own.
Instrument egress success rate to your top five managed dependencies. This is where the rising public cloud network outage category actually lands.
Segment client side error metrics by region and ASN. Without segmentation a regional failure looks like background noise until it is large enough to be obvious, which is far too late.
Rehearse the traffic shift. If failover has never been executed under time pressure, assume it will not work when you need it. Run it deliberately during business hours at least twice a year.
Route support volume into the incident channel. During asymmetric failures, customers detect the problem before your monitoring does, and that is not a failure of your team, it is a property of the failure mode.

The Bottom Line

The late August 2026 data tells a fairly clear story. Public cloud network outages rose 17 percent globally and 22 percent in the United States in a single week, while the overall outage total stayed flat. A Tier 1 backbone provider took out reachability across thirty plus countries in a pattern that included at least one false recovery and reached peak impact more than an hour after the first symptom. None of that was caused by anyone's deploy, and none of it would have appeared on a conventional internal health dashboard.

Good network outage incident response does not mean building your own transit network. It means accepting that a meaningful share of your outages will originate in infrastructure you neither own nor can fix, and then optimising for the parts you do control: detecting from outside your own failure domain, mapping blast radius before communicating, mitigating with traffic shifts and deliberate degradation, and refusing to declare resolution until the signal has been clean for long enough to trust. Teams that make those four changes will handle the next backbone event as a managed degradation. Teams that do not will handle it twice.