GitHub knows that millions of developers depend on its platform for critical work. That's a responsibility the company takes seriously. After recent availability issues, GitHub committed to both reliability improvements and better communication during and after incidents. Guided by transparency, accuracy, and timeliness, GitHub has introduced three key changes to its status page: a new incident severity level, per-service uptime metrics, and more granular components—like one specifically for Copilot AI model providers. Here's what these changes mean for you.
What prompted GitHub to update its status page?
GitHub recognized that its previous incident classification system didn't always reflect real user impact. For example, even minor service issues were labeled as partial outages, making users think a service was completely unavailable when it was still functioning. This led to confusion and distrust. To improve communication, GitHub focused on three principles: transparency, accuracy, and timeliness. The changes aim to provide clearer, more honest updates about service health, helping users understand whether a service is truly down or just experiencing minor degradation. Additionally, developers wanted to see historical reliability data for individual services, not just a single overall uptime number. GitHub responded by publishing per-service uptime percentages and adding more detailed components for specific features like Copilot AI model providers.
What is the new “Degraded Performance” state and why was it added?
The new Degraded Performance severity level sits alongside the existing Partial Outage and Major Outage states, creating a three-tier system. Degraded Performance means a service is operational but impaired—you might see elevated latency, reduced functionality, or intermittent errors affecting a small percentage of requests. Previously, any issue was automatically classified as a Partial Outage, overstating the impact. This change allows GitHub to more accurately convey the true nature of an incident. For instance, if only a subset of users experience slow response times, that's Degraded Performance, not a partial outage. This helps users make better decisions about whether to investigate further or wait for recovery.
How does GitHub now display per-service uptime?
GitHub now publishes per-service uptime percentages directly on its status page, covering the last 90 days. For example, you can see the uptime for Actions, Pages, or Copilot individually, rather than just an overall number. These percentages are calculated based on the number of incidents, their severity, and their duration for each service, using industry-standard methods. Each severity level carries a specific “downtime weight”: a Major Outage counts 100% of the duration as downtime; a Partial Outage counts 30%; and Degraded Performance counts 0% (since the service remains functional). So if a service had a 1-hour Partial Outage, that translates to 18 minutes of effective downtime in the uptime calculation. This gives you a clearer, more honest view of each service's reliability.
How is uptime calculated with the new severity levels?
Uptime percentages are computed using a weighted downtime model. For each incident, the duration is multiplied by a severity-specific factor: 100% for Major Outage, 30% for Partial Outage, and 0% for Degraded Performance. The total weighted downtime is then subtracted from the total time period (90 days) to calculate uptime. For example, if a service experienced a 1-hour Partial Outage, only 18 minutes (1 hour × 30%) count as downtime. A Degraded Performance incident adds no downtime. This method ensures that only significant service interruptions affect the uptime metric, while minor impairments don't skew the numbers. The result is a more accurate representation of a service's reliability, helping users trust the data and make informed decisions about their workflows.
What more granular insights are being added to the status page?
GitHub is introducing more detailed components on the status page to give clearer visibility into specific aspects of the platform. The first example is a dedicated “Copilot AI Model Providers” component. Previously, all Copilot-related issues were lumped into a single service. Now, if a third-party AI model provider experiences an outage, GitHub can communicate it separately, so users know the core Copilot service might still be healthy. This granularity helps developers understand exactly what's affected—whether it's GitHub itself, a dependency, or a regional issue. Over time, GitHub plans to add more such components for other services, making status updates more precise and actionable. This change aligns with the broader goal of reducing noise and increasing trust in the platform's health reporting.
What are the three severity levels and what do they mean?
GitHub's incident classification now includes three distinct levels:
- 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, only two levels existed (Partial and Major Outage), which forced minor issues into the Partial Outage category. The addition of Degraded Performance allows GitHub to label incidents more accurately, reducing false alarms. For example, if a service is slow but still working, users see “Degraded Performance” rather than “Partial Outage,” making it easier to assess real impact. This three-tier system also improves the uptime calculation, as Degraded Performance counts as 0% downtime.