Service health reporting gets more granular
GitHub has introduced three changes to its status page aimed at giving developers a clearer picture of platform health. The updates — a new incident severity level, per-service uptime metrics, and a dedicated component for Copilot AI model providers — are designed to distinguish between different types of disruptions and make historical reliability data easier to parse.
- A new "Degraded Performance" state for more accurate incident classification
- Per-service uptime metrics published for each service
- More granular insights on service disruptions, starting with a dedicated "Copilot AI Model Providers" component for clearer communication around model provider availability
A new severity tier
The status page now supports a third incident classification: Degraded Performance. This sits alongside the existing Partial Outage and Major Outage states, creating a three-tier system that better reflects the range of issues that can affect GitHub services.
| State | What It Means |
|---|---|
| Degraded Performance | The service is operational but impaired. You 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. |
Previously, all incidents were labeled as at least a partial outage, even when the disruption was minimal. That over-classification often made it look like a service was unavailable when it remained functional, which didn't accurately convey the actual user impact.
Uptime history for every service
GitHub now publishes per-service uptime percentages for the last 90 days directly on the status page. The numbers are derived from incident count, severity, and duration for each service, using industry standard status page calculations.
Each severity level maps to a specific downtime weight:
| Severity | Downtime weight |
|---|---|
| Major Outage | 100% — the full duration counts as downtime |
| Partial Outage | 30% — reflects significant but not total service loss |
| Degraded Performance | 0% — does not count as downtime; the service remains functional |
For instance, a 1-hour Partial Outage within a 90-day window counts as 18 minutes of effective downtime for the uptime calculation — not the full hour. A Degraded Performance incident carries no weight in the uptime percentage.
Separating model provider issues from Copilot incidents
A new component, "Copilot AI Model Providers", now tracks issues related to underlying AI model availability. Previously, an outage at a model provider triggered an incident against the Copilot service as a whole, even when only one model was affected. That didn't match the experience of many users: features like GitHub Copilot Chat and GitHub Copilot cloud agent (formerly coding agent) support multiple models, and when one is unavailable, users can pick an alternative or rely on auto model selection to route requests to the best available option.
Going forward, model-related disruptions will be reported under the dedicated "Copilot AI Model Providers" component rather than the broader "Copilot" one. Public incident updates will continue to specify which models are impacted.
Transparency when it matters
The expanded severity classification, per-service uptime figures, and granular Copilot component are intended to give operators the context needed to assess impact and make decisions. GitHub positions these changes as part of its ongoing effort to improve communication during incidents, particularly given the platform's role as critical infrastructure for many development teams.
