GitHub upgrades status page with real-time service insights for devs

GitHub serves as the backbone for millions of developers, and ensuring its reliability demands both robust infrastructure and clear communication. After addressing recent availability challenges, the platform is now rolling out critical improvements to its status page to enhance transparency during service disruptions.

A three-tier incident system for clearer communication

Previously, GitHub’s status page relied on two severity levels—Partial Outage and Major Outage—to classify incidents, which often led to confusion. A minor slowdown or intermittent errors were sometimes labeled as a partial outage, even when the service remained functional. To address this, GitHub introduced a Degraded Performance state, creating a more nuanced three-tier system:

• Degraded Performance: The service operates but with noticeable issues, such as higher latency or reduced functionality affecting a small fraction 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 change ensures incidents are classified based on actual user impact rather than perceived severity, providing developers with more accurate context during service disruptions.

Per-service uptime metrics for better reliability tracking

GitHub now displays per-service uptime percentages over the last 90 days directly on its status page. Instead of a single overall uptime figure, developers can assess the reliability of individual services such as GitHub Actions, GitHub Pages, or the API.

The uptime calculation follows industry-standard practices, where each severity level contributes differently to the final percentage:

• Major Outage: Counts as 100% downtime for the full duration.
• Partial Outage: Counts as 30% of the incident duration.
• Degraded Performance: Does not count as downtime, as the service remains operational.

For example, a one-hour Partial Outage would equate to 18 minutes of effective downtime in the 90-day uptime calculation. This granular approach helps teams make informed decisions about their workflows based on real data.

Dedicated Copilot AI Model Providers component

GitHub Copilot relies on multiple AI models, and disruptions were previously reported under a single “Copilot” component. This often masked the true impact of model-specific outages, as some features like GitHub Copilot Chat support alternative models or auto-selection.

To improve clarity, GitHub introduced a new Copilot AI Model Providers component on its status page. Now, incidents affecting specific models will be reported separately, providing developers with precise updates on which models are unavailable and how alternative options can be used. Public incident reports will continue to detail affected models and expected resolution timelines.

Why these changes matter for developers

Transparency during service disruptions is crucial for teams relying on GitHub as critical infrastructure. The refined incident classification, per-service uptime metrics, and dedicated Copilot AI Model Providers component empower developers to:

• Quickly assess the scope of an incident and its potential impact on their workflows.
• Make data-driven decisions about whether to pause or adjust operations based on real-time reliability data.
• Gain deeper insights into GitHub Copilot’s model availability, ensuring smoother AI-assisted development experiences.

GitHub’s commitment to clear communication reflects its understanding that developers need more than just uptime percentages—they need actionable context to maintain productivity. As the platform evolves, these improvements underscore the importance of both technical resilience and transparent incident reporting in modern software development.