Did you know? · No. 08 · Trivia ·
A 43-second network partition led to 24 hours of degraded GitHub service

On October 21, 2018, at 22:52 UTC, maintenance replacing failing 100G optical equipment cut connectivity between GitHub’s US East Coast network hub and its primary East Coast data center. The link returned in 43 seconds. But the split triggered automated database failover and left the two sites with writes the other did not have. GitHub reported 24 hours and 11 minutes of degraded service, with no user data lost.
For a smaller site, a database split can create a much longer problem than the network break itself. Your app may keep accepting writes while replicas, queues, or backup systems disagree about which copy is current. Recovery then becomes a careful data-integrity exercise, not a quick switch back.
Try this on your site
This week, document what your database and application do when regions or replicas cannot communicate. Run a controlled failover drill and confirm who can stop writes, choose the authoritative copy, and validate data before traffic returns.
Share this fact
Each fact is checked against the primary sources listed. Spotted an error? Email the Status Is UP team. Status Is UP helps owners improve their sites; it is not an uptime monitor. For live outage status, see Status Is Down.