Internet Outage Atlas · About

ABOUT
THE ATLAS

What this site is, how it is organized, and who built it

What this site is

Internet Outage Atlas is a broadsheet-style record of landmark internet failures. It treats outages as infrastructure events with patterns, causes, and blast radius that can be documented and compared over time.

This is not a live dashboard and not a status page for one company. It is a reference work. The site follows the shared layers that let failures spread, including naming, routing, edge networks, identity, control planes, and the physical systems underneath them.

The project was researched, written, designed, and built by Jonathan R Reed.

Scope

What the atlas covers

  • Major outages where the blast radius escaped one product or one vendor
  • Failures in shared layers like DNS, BGP, CDN, identity, and control planes
  • Incidents with strong public reporting, postmortems, or primary technical analysis
  • Cases that help explain how internet concentration turns local mistakes into public outages
Structure

How the site is organized

  • The homepage handles the core narrative and the most defining incidents
  • The timeline isolates a smaller canon that best explains shared infrastructure failure
  • The archive and taxonomy expand the record into supporting cases and recurring failure classes
  • The About file now includes the methodology and source record for the atlas
Editorial approach

Editorial approach

  • Write clearly and keep the failure mode specific
  • Prefer shared dependency patterns over vendor branding
  • Treat outages as historical records, not product marketing copy
  • Keep the design readable in both light and dark theme without losing the atlas character
Methodology and Sources · Integrated Record

How This Atlas Was Built

Inclusion Criteria

An incident belongs here if it produced meaningful U.S. user impact, revealed a failure mode worth tracking, or clarified how shared infrastructure actually breaks. Meaningful means more than a short wobble and more than one service feeling it.

Minor degradations stay out. So do incidents that can only be verified through social posts or cases where the sourcing is too thin to trust the key facts.

Handling Disputed Details

When authoritative sources conflict, this atlas uses the most conservative figure and notes the dispute. Financial loss numbers are used as scale markers, not as precise accounting.

Source Hierarchy

  • Company postmortems and official incident reports
  • Regulatory filings (FCC, CRTC, and equivalent bodies)
  • Technical analyses by BGP monitoring services (Cloudflare Radar, RIPE NCC, RouteViews)
  • Investigative journalism with technical depth and primary sources cited
  • Peer-reviewed research and major conference proceedings (USENIX, SIGCOMM)

Scope and Coverage

  • Launch corpus built around the strongest incidents documented in the merged report
  • Homepage remains a curated narrative, while timeline and archives broaden coverage
  • Temporal scope: historical incidents through March 2026
  • Geographic focus: incidents with significant U.S. user impact prioritized
  • No real-time monitoring component; this is a historical record