Introduction

GitHub serves as the backbone for millions of developers worldwide, hosting critical code repositories and collaboration tools. Recognizing the immense responsibility, the platform has been investing in reliability improvements and incident communication. In a recent update, GitHub announced three key enhancements to its status page, aimed at delivering more accurate, detailed, and timely information about service health. These changes introduce a new incident severity level, per-service uptime metrics, and more granular insights into disruptions—starting with the Copilot AI Model Providers. Together, they reflect GitHub's commitment to transparency and user trust.

New Incident Severity: Degraded Performance

Previously, any service issue was categorized as at least a "Partial Outage," even when the problem was minor. This often misrepresented the actual user experience, causing unnecessary alarm. To address this, GitHub has added a third tier: Degraded Performance. This severity level sits alongside the existing Partial Outage and Major Outage states, creating a three-tier system that more accurately reflects the spectrum of possible disruptions.

What Each Level Means

• Degraded Performance: The service remains operational but may experience elevated latency, reduced functionality, or intermittent errors affecting a small percentage 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 classification upgrade ensures that users receive a more truthful picture of service health. For example, if only a minor latency spike occurs, it will no longer be labeled as an outage, reducing confusion and overstatement.

Per-Service Uptime Percentages on the Status Page

Another major change is the public display of per-service uptime percentages over the last 90 days. Instead of a single overall uptime figure, GitHub now shows reliability metrics for each individual service directly on the status page. This allows users to quickly assess the track record of services they rely on most.

How Uptime Is Calculated

The uptime calculation follows industry-standard methodologies, factoring in the severity and duration of incidents for each service. Each severity carries a specific downtime weight:

For instance, if a service experienced a 1-hour Partial Outage over 90 days, the effective downtime would be 18 minutes (30% of 60 minutes), not the full hour. This weighting provides a more nuanced view of reliability, acknowledging that not all incidents are equal.

Granular Insights into Service Disruptions

To further improve communication during incidents, GitHub is rolling out more specific component-level detail. The first implementation is a dedicated Copilot AI Model Providers component on the status page. This allows the team to clearly indicate when issues are limited to external model provider availability rather than affecting the entire Copilot service. Users will see exactly which part of the stack is impacted, reducing ambiguity.

Future Expansion

GitHub plans to extend this granularity to other services over time, enabling faster diagnosis and more targeted updates. By breaking down complex systems into observable components, the platform aims to provide the transparency that developers need to make informed decisions.

Conclusion

These enhancements—Degraded Performance, per-service uptime, and granular component insights—represent significant strides in how GitHub communicates service health. They align with the principles of transparency, accuracy, and timeliness. Developers can now better understand the true state of the platform, plan around potential disruptions, and trust that the status page reflects reality. As GitHub continues to invest in reliability, these communication improvements ensure that users stay informed and empowered.