Summary

  • A maintenance command cut Facebook's backbone connections. Its name servers were still working, but the internet could no longer reach them.
  • Recovery meant restoring engineers' access and then bringing services back carefully. Outside routing observations do not provide a stopwatch for every user's outage.

Facebook would not open. Trying Instagram or WhatsApp offered no simple escape: on 4 October 2021, the same outage reached all three. To somebody trying to get in touch, which part of the network had failed was a secondary concern. The immediate problem was getting a familiar means of contact back.

The people responsible for fixing it had an access problem of their own. Some of the routes engineers normally used to reach their systems were unavailable too. Restoring a service for its users first required recovering the means to repair it.

Stranger still, some crucial machines had never stopped working. The DNS servers—the machines that help turn a name such as facebook.com into an address—remained operational, according to the company. The internet had lost the route to them. That is why this was not simply a story of broken servers waiting to be switched back on.

The command that reached too far

According to the company's engineering account, the trouble began during routine maintenance. A command intended to assess spare capacity on the global backbone instead disconnected its links. Data centres lost their connections to one another. A bug in an audit tool meant that a check designed to stop this sort of command did not stop it.

The name servers then did something their design told them to do. Unable to reach the data centres through the backbone, they withdrew their BGP route announcements. BGP is how networks tell one another which destinations they can reach. With those announcements gone, an operating DNS server could no longer be found over the internet.

From outside, the disappearance was visible, but its cause was not. Cloudflare recorded a surge in routing changes around 15:40 UTC and noticed the withdrawal of routes to Facebook's DNS prefixes at 15:58. Other Facebook prefixes remained routed. This was not every Facebook address disappearing, still less the whole internet collapsing.

Those observations fit the operator's account. They do not independently reveal the maintenance command, the failed check or what engineers saw internally. Nor does the eighteen-minute gap between observations establish the only opportunity to detect the problem.

Repair needed an entrance

The operator described losing both its ordinary network access and its out-of-band access—the separate management route intended for use when normal access fails. DNS loss also broke internal investigation tools. These were overlapping obstacles; the account does not establish that DNS failure itself caused the out-of-band path to fail.

Engineers were sent on site to restore access. Physical and system security made getting in and changing the equipment harder, the company said. It is tempting to turn this into a story about one engineer racing towards a rack. The record does not supply that scene, a headcount or a journey time.

And reaching the equipment was not the end. Bringing a global service back all at once risked sudden traffic and power demands. The company described restarting cautiously to avoid creating another problem during recovery. Earlier disruption exercises helped with that work, although a complete loss of the global backbone had not been rehearsed.

Two kinds of “back”

Cloudflare saw BGP activity return around 21:00 UTC, with a peak at 21:17. By 21:28, global connectivity and DNS resolution appeared to be back. Applications could still take longer to recover.

The interval from its 15:58 observation to 21:28 is 330 minutes. That is a useful description of two observations—not a universal service-outage duration, and certainly not a measurement of how long engineers spent travelling. Reconnecting a network and restoring a usable application are different milestones.

Repeated attempts to reach the missing services also created extra DNS work elsewhere. Yet Cloudflare reported that most queries to its 1.1.1.1 resolver still finished in under ten milliseconds, even as the slowest queries became slower. The disruption spread beyond Facebook without making every other service unusable.

The incident remains revealing because recovery had its own dependencies. Working servers were not enough; engineers needed access, and restored links still needed a careful restart. These two contemporary accounts explain that difficulty in 2021. They do not establish what Meta Platforms has implemented since, or how its network is arranged today.

Correction, 21 October 2026: This account now distinguishes the loss of management access from DNS-dependent tool failures and network observations from application recovery. Earlier claims equating the outage with engineers' travel time, or drawing conclusions about present-day architecture from the 2021 reports, have been removed.