Introduction
GitHub, the platform relied upon by millions of developers for critical work, has long understood the importance of clear communication regarding service health. Following earlier commitments to improve reliability, the company is now rolling out significant enhancements to its status page. These changes focus on three key areas: more precise incident classification, publicly available per-service uptime metrics, and granular insights into specific service dependencies. The goal is to provide developers with a clearer, more accurate picture of platform performance during both normal operations and disruptions.
A New Severity Level: Degraded Performance
Previously, GitHub classified all incidents as either a partial outage or a major outage. This binary approach often misrepresented the actual user experience. For example, a service experiencing elevated latency or intermittent errors that affected only a small percentage of requests was labeled as a partial outage, leading users to believe the service was largely unavailable when it remained functional.
To address this, GitHub has introduced a third severity level: Degraded Performance. This new category sits between full functionality and partial outage, creating a three-tier system that more accurately reflects the spectrum of issues. The table below summarizes each severity state:
- Degraded Performance – The service is operational but impaired. Users may experience elevated latency, reduced functionality, or intermittent errors affecting a small subset of requests.
- Partial Outage – A significant portion of the service is unavailable or severely impacted for a meaningful number of users.
- Major Outage – The service is broadly unavailable, affecting most or all users.
This refined classification ensures that incident labels accurately convey the actual impact, helping developers prioritize their responses and manage expectations.
Per-Service Uptime Percentages Now Public
Transparency extends to historical performance. GitHub now publishes per-service uptime percentages directly on its status page, covering the preceding 90 days. This allows users to quickly assess the reliability track record of each individual service without needing to manually aggregate incident reports.
The uptime calculation uses an industry-standard methodology where each severity level carries a specific downtime weight:
- Major Outage – 100% of the incident duration counts as downtime.
- Partial Outage – 30% of the incident duration counts as downtime, acknowledging significant but not total service loss.
- Degraded Performance – 0% of the incident duration counts as downtime, since the service remains functional.
For instance, if a service experiences a one-hour partial outage over a 90-day period, the effective downtime would be 18 minutes (30% of one hour), not the full hour. This weighting provides a more nuanced view of actual availability. Note that degraded performance incidents do not contribute to downtime at all, reflecting their minimal impact on core functionality.
More Granular Insights: Starting with Copilot AI Model Providers
In addition to overall service status, GitHub is introducing dedicated components that break down disruptions into finer-grained categories. The first such component is "Copilot AI Model Providers", which will provide specific status updates related to the underlying AI models that power GitHub Copilot. This means that if a particular model provider experiences an issue, GitHub can communicate that clearly without conflating it with the broader Copilot service or other features.
This approach allows users to understand exactly which dependency is affected, reducing confusion and enabling more targeted mitigation strategies. Future expansions to other service areas are expected, further enhancing the granularity of GitHub's status communication.
Conclusion
These three changes—accurate incident severity, public uptime metrics, and granular component tracking—represent a significant step forward in GitHub's commitment to transparency. Developers now have better tools to assess platform health, understand the true nature of incidents, and make informed decisions about their workflows. As GitHub continues to invest in reliability, its communication strategy evolves to match the expectations of a community that depends on clarity and honesty.
For more details, visit the GitHub Status Page.