FIELD NOTE / 2026.09.224 MIN READ / 5 SOURCES

Facebook’s 2021 BGP Outage: The Configuration Change That Disconnected a Company from the Internet

Meta's 2021 outage began with a backbone maintenance command, cascaded into BGP withdrawals and DNS failure, and disabled many of the internal tools engineers needed to recover.

A routine backbone maintenance command disconnected Meta’s data centers from one another

On October 4, 2021, Meta experienced a global outage affecting Facebook, Instagram, WhatsApp, and internal systems. Meta’s engineering account says a command intended to assess backbone capacity unintentionally took down the connections in the company’s global backbone network.[1] An audit system was supposed to prevent dangerous commands, but a bug in that protective tool failed to stop this one. The initial failure was therefore not BGP itself. It was a backbone-control action that removed the connectivity on which Meta’s external routing depended.

The safety tool failed at the same moment it was needed

Guardrails are software too. A command-review mechanism can reduce risk only if its own failure modes are tested as rigorously as the infrastructure it protects.

DNS sites withdrew BGP advertisements because they could no longer reach healthy data centers

Meta’s smaller edge facilities provided authoritative DNS and advertised their reachability to the Internet through BGP. When the backbone disappeared, those DNS sites detected that they could no longer communicate with Meta’s data centers and withdrew their BGP advertisements as designed.[1] That protective behavior turned an internal backbone failure into external disappearance. The DNS servers themselves were not necessarily broken; they intentionally stopped claiming service because their backend dependency was unhealthy.

A correct fail-safe behavior amplified a larger system failure

Locally correct safety mechanisms can combine badly. Withdrawing unhealthy DNS routes prevented bad answers, but it also removed the names users and operators needed to reach the company.

Cloudflare observed Facebook’s routes vanish from the global Internet

Cloudflare’s monitoring saw Facebook’s DNS names begin returning failures and observed BGP route withdrawals that made Meta’s authoritative name servers unreachable.[2] From outside, the company looked as though its networks had been pulled away from the Internet. This illustrates the difference between servers being powered on and services being reachable. BGP is the mechanism by which networks tell the world where to send traffic; when those advertisements disappear, healthy machines can become effectively nonexistent to external users.

Reachability is part of service state

Application monitoring that focuses only on hosts inside a data center can miss the more fundamental question: does the rest of the Internet still have a route to those hosts?

The outage disabled many of the internal tools engineers normally used for recovery

Meta said the total loss of backbone connectivity and DNS also broke normal internal access and diagnostic tools.[1] Engineers had to send people physically to data centers, where security controls and the difficulty of modifying core routers slowed intervention. This is a classic resilience trap: operational tooling depends on the infrastructure it is meant to repair. Out-of-band management must be genuinely independent, with separate paths, credentials, and naming where necessary.

The repair system needs a different failure domain

A recovery channel that shares DNS, backbone, identity, or routing dependencies with production may disappear during exactly the incident that requires it.

Independent measurements showed the outage lasted for hours and involved more than DNS

ThousandEyes observed the sequence of route withdrawal, DNS unreachability, and eventual restoration, concluding that the incident extended well beyond a conventional DNS outage.[3] Those outside measurements were valuable because Meta’s own internal visibility was degraded. External telemetry can provide an independent view of what customers and peers actually see when internal monitoring is isolated with the failed network.

BGP behaved according to the reachability information Meta supplied

BGP’s base specification defines how autonomous systems exchange routes and withdraw destinations that are no longer reachable.[4] The October outage was not a case of BGP inventing a bad route. Meta’s edge systems withdrew routes because the underlying backbone state told them the service was unhealthy. This matters historically because the popular label ‘BGP outage’ can obscure the causal chain. BGP was the propagation mechanism through which a backbone failure became global absence.

DNS dependency made the company’s disappearance more complete

DNS translates service names into addresses, and RFC 1035 defines the distributed query system applications rely on.[5] During Meta’s outage, authoritative DNS servers became unreachable because their network routes had been withdrawn. The combination removed both familiar names and many direct network paths. Recovery was correspondingly difficult because internal services also depended on naming. The incident showed that DNS, routing, backbone capacity, and operational access form one availability system even when they are managed by separate teams.

Why Facebook’s 2021 outage belongs in software-failure history

Meta’s 2021 outage belongs in software history because it was a cascade of individually understandable mechanisms. A maintenance command removed backbone connectivity, a flawed audit guardrail failed to block it, DNS sites interpreted the backbone loss as service failure, BGP withdrawals removed those sites from the Internet, and internal tools lost the same network dependencies engineers needed for repair. The lesson is not merely to be careful with router commands. Critical infrastructure needs independent recovery paths and tests that ask what happens when safety systems, naming, routing, and operator access fail together.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.

Contribute / Corrections

Improve the record.

Use this moderated submission form to suggest a correction, provide a source, challenge a priority claim or identify a missing contributor. Submissions are treated as research leads, not automatically published comments.