The Network That Vanished

On October 4, 2021, Facebook, Instagram and WhatsApp became unreachable. From outside Facebook, Cloudflare watched routes disappear and domain-name lookups fail. Inside the company, the outage also disabled tools engineers normally used to investigate and repair failures. The system had not merely stopped delivering its services. It had made reaching the broken machinery harder.

This is a retrospective of that day's outage, drawing on Facebook's more detailed account published October 5 as well as external network observations. Those perspectives establish different things: the company describes its internal failure and recovery; Cloudflare records what it could see from the internet. Neither supplies a census of every conversation or business transaction interrupted.

The revealing feature is not that a large network failed. Networks fail. It is how many apparently separate functions depended on the same network continuing to work. Several app icons were not several independent ways to stay connected. And a recovery mechanism was not independent merely because it was intended for emergencies.

The failure behind the missing names

Facebook's October 5 engineering account, written by Santosh Janardhan, identifies the initiating event as a command issued during routine maintenance. Its intended purpose was to assess the availability of global backbone capacity. Instead, the company says, it took down all connections in that backbone, disconnecting its data centers globally.

The backbone was the network joining Facebook's computing facilities. Requests arriving near a user could travel through it to the larger data centers where information was retrieved and processed. Breaking those connections therefore did not leave a single isolated feature unavailable. It interrupted the relationships between facilities on which the services depended.

There was supposed to be a safeguard. Facebook says an audit tool checked commands of this kind, but a bug prevented it from stopping this one.

That matters more than the irresistible shorthand about somebody typing the wrong thing. A command with a global effect and a failed check is a systems story. The supplied account does not establish enough detail to assign personal blame or reconstruct the precise command. It does establish that the protective mechanism did not contain the initiating error.

The next failure followed from a rule designed to support reliability. Facebook's DNS servers withdrew their BGP advertisements when they could no longer communicate with its data centers. Ordinarily, withdrawing an unhealthy location can help avoid directing traffic somewhere that cannot serve it. Here, the whole backbone was unavailable, so the withdrawal happened across those locations.

DNS translates a name such as facebook.com into an address. BGP distributes information about how networks can reach addresses. The distinction is important: according to Facebook, its DNS servers remained operational, but the routes needed to reach them disappeared. A working address book is not much help when nobody can get to it.

“DNS broke” describes a symptom. It does not explain the initiating failure. The chain ran from a backbone disruption, through a health-dependent routing decision, into the inability to resolve the services' names.

What the outside observer could establish

Cloudflare's analysis of the outage, by Celso Martinho and Tom Strickx, supplies an external view rather than an independent inspection of Facebook's internal systems. Its engineers initially worried that their own DNS resolver was failing. They then confirmed that Facebook and its affiliated services were unreachable.

Cloudflare reports a spike in routing changes around 15:40 UTC and says that by 15:58 it had noticed Facebook was no longer announcing routes to its DNS prefixes. Crucially, it also records that some other Facebook IP addresses remained routed. The company had effectively vanished as a usable service, not literally withdrawn every address associated with it.

That qualification keeps the metaphor from becoming a false technical claim. To someone trying to send a message, the distinction was probably small. To someone diagnosing the event, it separates a specific dependency failure from a story about the whole internet forgetting Facebook existed.

Cloudflare's resolver data showed facebook.com becoming unavailable around 15:50 UTC and returning around 21:20. Those timestamps measure name availability from that observer's service; they are not a promise that every app feature recovered for every user at the same instant. Cloudflare itself warned that the services could take longer to come online after routing and DNS returned.

The outside observations support the broad sequence in Facebook's explanation. They do not independently verify the audit-tool bug, the maintenance command's intention or every step of internal recovery. Keeping that boundary visible is how a postmortem remains evidence rather than turning into an authorized legend.

The repair route shared the failure

Facebook says both its primary and out-of-band network access were down. The loss of DNS also broke many of the internal tools normally used to investigate and resolve incidents. Engineers had to go to the data centers to debug the problem and restart systems.

“Out-of-band” usually promises a management route separate from ordinary service traffic. In this event, the company reports that route was unavailable too. The public account does not provide a complete dependency diagram explaining every management-path failure. It does provide a demanding test for any recovery claim: does the supposedly separate route still work when the main system is absent?

Physical access was not a simple escape hatch. Facebook describes facilities designed to be difficult to enter and equipment designed to resist modification even after someone reaches it. Activating the secure access procedures took additional time.

There is no need to turn that into a joke about security being useless. Those protections exist because unauthorized access is dangerous. Janardhan explicitly defended the tradeoff between stronger day-to-day security and slower recovery from a rare event. That is a position worth examining, not a confession that the locks should be removed.

The better question is whether authorized emergency access can be rehearsed under the conditions that make it necessary. A recovery procedure tested while authentication, naming and management services are healthy may tell you little about recovery when those dependencies disappear together. That is a general design lesson drawn from the sequence, not a claim that Facebook disclosed exactly such a testing arrangement.

A system's capacity to correct itself is part of its capacity to operate. If the tools for seeing and repairing a failure depend on the failed layer, recovery begins with rebuilding the conditions for recovery. The incident gets a head start.

Coming back was another engineering problem

Restoring connectivity did not make it safe to switch everything on at once. Facebook says individual data centers reported drops in power consumption measured in tens of megawatts. A sudden return of demand could stress systems ranging from electrical infrastructure to caches.

The company credits its “storm” exercises with helping it manage the return. Those drills simulated failures involving a service, a data center or an entire region. Experience gained there helped engineers increase load carefully, and Facebook reports that services returned without further systemwide failures.

This is the part a purely cynical account would skip, which is why it belongs here. Preparation did useful work. The people restoring the network were not simply improvising in a room full of apology templates.

But the same postmortem says Facebook had not previously run a storm simulating the loss of its global backbone. The distinction is between preparation that transfers to part of an emergency and preparation that has tested the emergency itself. Successful restart experience did not prove that the initiating failure was contained, or that the route to the equipment would remain available.

The company's initial update, subsequently updated October 5, attributed the outage to a faulty configuration change rather than malicious activity and said there was no evidence that user data had been compromised. Those are Facebook's statements. They should not be inflated into an independent security finding. Nor should the absence of reported compromise be mistaken for the absence of harm: losing access is a different kind of failure from losing confidentiality.

Three icons, one shared interruption

For users, the dependency diagram was largely invisible. Facebook, Instagram and WhatsApp offered different interfaces and uses, but during this incident they were not independent fallbacks for one another.

Cloudflare observed increased DNS queries to Twitter, Signal and other services during the outage. That is evidence of additional lookup activity, not proof that people successfully moved their relationships elsewhere. A reachable alternative is only the beginning. The person you need must also be reachable there.

Consider a hypothetical small business that uses one service to display products and another to arrange orders. If both depend on the same failed infrastructure, two channels do not provide the protection their separate branding suggests. That example illustrates the dependency; it is not a reported account of a particular business's losses.

The same reasoning applies to a family or neighborhood group. Communication is collective. One member can install another app in minutes and still have no useful fallback if everyone else is waiting in the unavailable one. Resilience cannot be measured solely by how many services an individual has downloaded.

This is where the coherenceism lens earns its keep: a system should be judged by how well it sustains the relationships it mediates, including when its preferred arrangement fails. Internal integration can make ordinary operation efficient while leaving the people outside the organization carrying a shared interruption. Corporate unity and public resilience are not synonyms.

That does not make fragmentation automatically superior. More providers can introduce their own costs, dependencies and confusing handoffs. Nor does an outage, by itself, settle a competition-policy argument. The narrower conclusion is strong enough: separate products cannot be counted as independent paths without examining what they share underneath.

A fallback has to preserve something useful

A practical standard follows. Operators should be able to demonstrate recovery access under the loss of the services it normally relies on, rehearse failures that cross regional boundaries, and distinguish restoration of network reachability from restoration of usable service. These are requirements suggested by the incident, not improvements these sources establish Facebook subsequently completed.

For communities and businesses, the corresponding question is not whether to maintain a perfect duplicate of every platform. It is which relationships need a usable alternate route before an outage arrives. An agreed contact method, an independently reachable notice or a limited offline record can preserve a specific function without recreating an entire social network. Any such arrangement still needs attention to privacy, consent and who would otherwise be left out.

Responsibility cannot be downloaded onto users as another preparedness chore. The operator controls the common infrastructure and has far more information about its dependencies. Users should not need a network-engineering education to discover that their backup channel shares the original channel's failure.

Facebook's outage made the arrangement briefly visible. The apps disappeared; the people and obligations behind them remained. Bringing the platform back was an engineering achievement. Keeping relationships from becoming wholly hostage to that restoration is the larger design obligation.

The next fallback should be tested with the main system switched off. Otherwise, it is just another feature waiting for the same apology.