GitHub is where millions of developers do their most important work, and that comes with a responsibility we take seriously. Earlier this year, we shared an update on GitHub’s recent availability issues and the work we’re doing to address them. Alongside those reliability investments, we have prioritized improving how we communicate during and after incidents, increasing the specificity of the data we provide and giving better insight into the platform’s health overall.

Guided by transparency, accuracy, and timeliness, we’re rolling out three changes to how we communicate service health—outlined below.

• 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

Improving accuracy

We’re adding a new incident severity level: Degraded Performance. This sits alongside our existing Partial Outage and Major Outage states, creating a three-tier system that more accurately reflects the spectrum of issues that can affect GitHub services.

Previously, even with minimal service disruption, all incidents were classified at least as a partial outage. This did not accurately reflect customer impact and led users to believe a service was unavailable even if it was still functional.

Per-service uptime on the status page

We are now publishing per-service uptime percentages over the last 90 days directly on our status page, so you can quickly understand each service’s recent reliability track record.

These uptime percentages are calculated based on the number of incidents, their severity, and their duration for each individual service. These calculations are based on industry standard status page calculations.

Each severity level carries a specific downtime weight:

For example, if a service experienced a 1-hour Partial Outage over a 90-day period, that would count as 18 minutes of effective downtime in the uptime calculation—not the full hour. A Degraded Performance incident, by contrast, would not affect the uptime percentage at all.

Insights on model provider service disruptions

We’ve added a new component representing Copilot AI model providers.

Previously, when a model provider experienced an outage, we declared an incident against the Copilot service, even when the impact was limited to a single model. That didn’t always reflect your experience, because many Copilot features, such as GitHub Copilot Chat and GitHub Copilot cloud agent (formerly coding agent) support multiple models. On those features, if one model is unavailable, you can choose an alternative model or use auto model selection to have Copilot pick the best available option for you.

Going forward, incidents related to model availability will be reported under the new “Copilot AI Model Providers” component instead of the broader “Copilot” component. We’ll continue to share details, such as which models are affected, through public incident updates.

Our continued commitment to transparency

We recognize that clear communication and transparency matter most when things go wrong. The Degraded Performance state, per-service uptime percentages, and dedicated Copilot AI Model Providers component are designed to give you the context and details you need to make confident decisions about your operations.

We know GitHub is critical infrastructure for your teams, and we are committed to ensuring our platform is available when and where you need it; and communicating effectively and transparently when it is not.

Written by

Related posts