After the GitHub Outage: Seven Lessons for Resilient SaaS
GitHub published an initial account on August 20 of an outage that lasted 7 hours and 47 minutes and disrupted GitHub.com, authentication, Actions, APIs, pull requests, issues and Copilot. It is a useful case study for every SaaS company: reliability is a product, operating and leadership capability built before the next traffic peak.
An infrastructure incident quickly becomes a product incident
GitHub said the event began when traffic reached a new peak and a critical infrastructure component in its Central US data centre failed to scale with it. Capacity pressure propagated, causing authentication failures and disruption across services. A customer does not experience the component; the customer experiences an inability to sign in, merge code, run a workflow or obtain an answer. A SaaS dependency map should therefore connect technical components to customer journeys. That reveals which shared dependencies can disable several capabilities together and supports a restoration order based on customer value rather than server health alone.
Capacity is an assumption that must be challenged
Planning around averages hides the point where a system breaks. Teams need explicit peak-load assumptions, growth rates, component limits and measured scaling time. A load test is valuable only when it includes shared services such as identity, queues, databases, authorisation and observability, rather than one headline endpoint. Defined headroom and alerts should trigger before saturation. Where a component cannot scale automatically, the operating decision must be visible: who adds capacity, which signal initiates action, how much is added and how long the change takes.
A shared dependency is a product decision
Authentication, APIs and workflow orchestration often serve many products. Shared layers improve development efficiency while concentrating risk. The answer is not to duplicate everything; it is to understand blast radius and create deliberate boundaries. A read-only capability may remain available, background work may wait safely in a queue, and an interface can show accurate state instead of failing without explanation. A degraded mode is a product contract: which actions remain safe, which are delayed, how duplicate execution is prevented, and how customers know what they should do next.
An untested runbook is only a document
During an incident, people operate with partial information across teams. A runbook should define roles, escalation paths, sources of truth, rollback options and decisions that require approval. The list must then be exercised. Short simulations expose missing permissions, inaccessible dashboards, ambiguous language and dependencies on a communication channel that may itself be overloaded. The operating objective is to shorten the path from detection to an accurate view of impact and a safe decision, not merely the time until somebody acknowledges an alert.
Transparency is part of the service
GitHub stated directly that the outage disrupted people trying to ship software and that the company had let them down. Direct language does not restore availability, but it establishes responsibility. During an event, customers need to know which services are affected, what is confirmed, what remains under investigation and when the next update will arrive. Afterwards, a useful review explains the mechanism and corrective actions without pretending all uncertainty has disappeared. Status, support and account teams should use the same operational picture; conflicting messages extend the damage after systems recover.
Measure recovery, not only uptime
A high aggregate availability figure can coexist with one long failure of a critical journey. Uptime should be complemented by time to detect, time to mitigate, restoration time by capability, accumulated backlog, failed or duplicated actions and time until the customer receives confirmation. Error budgets are more useful when connected to journeys such as sign-in, payment, deployment or data export. Journey-level measures help leadership decide where investment is needed and prevent a local improvement from hiding a systemic weakness.
The leadership conclusion: reliability needs budget and ownership
Reliability cannot belong only to infrastructure teams while the roadmap rewards only new features. Leadership must reserve capacity for dependency work, load testing, architectural simplification and incident exercises; define who can stop a release; and test whether growth goals match system capability. GitHub’s event is a reminder that a mature platform can still be affected by the interaction of record traffic and a critical component. Resilient SaaS is not software that never fails. It limits impact, recovers in a controlled way, communicates honestly and turns each incident into a measured investment in a stronger system.