GitHub suffered ~19-hour degraded service on April 20-21, 2026, caused by a serialization error that broke code scanning, code quality analyses, and project board updates.
Key Takeaways
Root cause: a serialization error in event publishing prevented code scanning default setup and code quality analyses from triggering on new pull requests.
Code scanning and code quality were down from 10:28 UTC to ~16:16 UTC on April 20; project board failures persisted until April 21, 05:04 UTC.
Project board fix required two steps: an event consumer code change plus a full reindex of affected project items.
GitHub is responding by strengthening schema validations and adding monitoring for publishing drops on critical internal hydro topics.
PRs opened during the outage still need a fresh push to trigger code scanning or code quality analysis retroactively.
Hacker News Comment Review
Commenters are broadly treating this as a reliability pattern, not an isolated incident, with historical uptime data cited as evidence of degradation after the Microsoft acquisition.
The silent failure mode drew sharp criticism: affected UIs reported no open pull requests even when dozens existed, a behavior commenters flagged as more dangerous than a visible error.
Strong consensus around multi-forge redundancy as a practical mitigation – CI sync jobs between forges and Sourcehut were the most-mentioned concrete alternatives.
Notable Comments
@cromka: “failing silently… showing ‘There aren’t any open pull requests’ even though there are dozens” – underscores how the failure mode could mislead teams into missing real work.
@Arcuru: recommends OSS projects add a simple CI job to mirror code across multiple forges and offer contributors an alternative submission path now, before the next outage.
