On the monthly availability report

Some institutions are worth admiring for their form before their content. GitHub has for years published a monthly availability report, a ledger of every incident with its duration and its cause, and the July 2026 edition, out on August 12, lists eight.

Read the causes rather than the durations. A metadata process changed a runtime value on running machines that a safeguard did not cover. A certificate expired. A DNS control plane misread incomplete data. An unrelated infrastructure change broke SSH key authentication. A cancelled database backfill took a misunderstood code path and dropped its backing table. Redis nodes failed during a planned configuration change. Seven of the eight are changes and expiries; one is an upstream provider. None is a bug in the product a user would name.

That distribution is the ordinary truth of operating a large system, and it is the truth a company can only see when it writes the ledger down and keeps writing it after the quarter where the numbers embarrass. The report's value to the reader is not that GitHub had a bad July. It is the accumulated series, which lets anyone compare their own postmortem archive against a well-run peer's and notice that the shapes match, a comparison old postmortems reward for the same reason.

Publishing the ledger is an engineering practice. Most organizations skip it, and the ones that do rarely know how normal their incidents are.