← Back to digest
HN Threads

GitHub's August 17 outage postmortem

What's this about?

GitHub published its account of the August 17 outage, which took down core workflows for close to eight hours. The most-discussed detail wasn't about the incident at all: monthly commits have grown from 1.4 billion in April to 2.9 billion — a doubling in four months.

What exactly does that commit number tell you?

Commit volume doubling in four months is not human behaviour. The world's developer population didn't double, and nobody started committing twice as often by hand. It's agent traffic showing up in the host's own metrics — agents commit more frequently and in smaller increments than people, because there's no cost to them in doing so. That reframes the outage: this is infrastructure built for a human rhythm meeting a load pattern it wasn't designed for, which is precisely the argument Cursor made this week for building Git storage like a database.

What's the community saying?

HN 340 points, 379 comments
  1. The missing apology was the loudest complaint. "Sorry" and "apologize" appear nowhere; "if you were trying to ship software that day, we let you down" was widely called corporate non-apology.
  2. The commit-growth number stopped people mid-thread — 1.4 billion to 2.9 billion since April, which several noted no company could absorb smoothly.
  3. The retry loop is the detail practitioners recognized. Errors triggered client-side retries that increased traffic during recovery — the failure mode that turns an incident into a long incident.
  4. Self-hosting advocacy surged, with several arguing a self-hosted forge would have had better uptime over the years, and connecting it to the same day's Cursor and GitHub-alternatives threads.
  5. Scepticism about the stated remedies, particularly the reliance on Azure, which one commenter argued is the source of the problems rather than the fix.
← A malicious Rust crate with a build-time payloadCursor's "Git at any scale" →