GitHub Overhauls Status Page with Degraded Performance State

TL;DR

• GitHub adds "Degraded Performance" state — incidents no longer default to "Partial Outage" when services are still functional
• Per-service uptime percentages now published for the last 90 days, weighted by incident severity
• New "Copilot AI Model Providers" component separates model outages from core Copilot service status
• Matters if you rely on GitHub's status page for incident response or SLA tracking

The Big Picture

GitHub's status page has been lying to you. Not maliciously, but structurally. Every incident, no matter how minor, triggered at least a "Partial Outage" classification. A 2% error rate spike? Partial Outage. One model provider down while three others work fine? Copilot Partial Outage. The result: developers treating every alert as a five-alarm fire, and SRE teams unable to distinguish real downtime from performance hiccups.

This matters because GitHub is critical infrastructure. When the status page says "Partial Outage," teams make decisions: roll back deploys, pause CI/CD pipelines, escalate to leadership. If that signal is noisy, those decisions are wrong. GitHub's new three-tier incident classification system — Degraded Performance, Partial Outage, Major Outage — finally gives the status page the resolution it needs to match reality.

The changes also address a transparency gap that's plagued GitHub since its availability issues earlier this year. Publishing per-service uptime percentages and breaking out Copilot model provider status are direct responses to developer complaints about vague incident reporting. This isn't just UI polish. It's GitHub acknowledging that when you're running production workloads, "something's wrong" isn't good enough.

How It Works

The new Degraded Performance state sits below Partial Outage in severity. It means the service is operational but impaired — elevated latency, intermittent errors, reduced functionality affecting a small percentage of requests. Critically, Degraded Performance incidents carry zero downtime weight in uptime calculations. The service is still up. It's just slower or flakier than normal.

Partial Outage now means what it should have meant all along: a significant portion of the service is unavailable or severely impacted for a meaningful number of users. Major Outage remains the top tier — the service is broadly unavailable, affecting most or all users. This three-tier system maps to how developers actually experience incidents. A 500ms latency spike is not the same as half your API calls returning 503s, which is not the same as the entire service being down.

The uptime percentages use weighted downtime calculations. Major Outage incidents count at 100% — the full duration is downtime. Partial Outage incidents count at 30%, reflecting significant but not total service loss. Degraded Performance counts at 0%. So a one-hour Partial Outage over 90 days translates to 18 minutes of effective downtime in the uptime calculation, not 60 minutes. This weighting system is borrowed from industry-standard status page practices, but GitHub's implementation of it is new.

The Copilot AI Model Providers component is the most developer-relevant change. Previously, if OpenAI's GPT-4 went down, GitHub declared a Copilot incident — even though Claude and other models were still available. For features like GitHub Copilot cloud agent and Copilot Chat that support multiple models, this was misleading. You could switch models or use auto model selection and keep working. Now, model provider outages get their own component. The broader Copilot component only shows incidents when the core service itself is impacted, not just one upstream provider.

GitHub's status page now displays 90-day uptime percentages for each service directly on the main page. No need to dig through incident history or calculate it yourself. The percentages update in real time as incidents are declared, reclassified, or resolved. This gives you a quick reliability snapshot before you commit to a deployment window or debug whether your CI failures are your fault or GitHub's.

What This Changes For Developers

If you're an SRE or platform engineer, this changes how you interpret GitHub incidents. A Degraded Performance alert no longer requires the same response as a Partial Outage. You can make more granular decisions: maybe you delay a non-critical deploy during Degraded Performance, but you don't page the on-call team. Maybe you increase retry logic temporarily instead of failing over to a backup system. The signal-to-noise ratio just improved.

For teams tracking SLAs or vendor reliability, the per-service uptime percentages are a game-changer. You can now hold GitHub accountable to specific numbers without manually parsing incident logs. If GitHub Actions shows 99.5% uptime over 90 days, you know exactly what you're getting. If it drops to 98%, you have data to escalate with your account team or adjust your own SLAs downstream.

The Copilot model provider split is huge for AI-assisted development workflows. If you're using Claude Opus 4.7 in GitHub Copilot, you care whether Claude is down, not whether some other model you don't use is having issues. The new component lets you see model-specific availability at a glance. If GPT-4 is degraded but Claude is fine, you switch models and keep coding. No more guessing whether "Copilot Partial Outage" means your workflow is actually broken.

This also impacts how you communicate incidents internally. When GitHub's status page says Degraded Performance, you can tell your team "GitHub is slow but functional" instead of "GitHub is down." That's a meaningful difference in how people react and what work gets paused. Clearer external communication from GitHub means clearer internal communication for you.

Try It Yourself

Visit status.github.com and check the per-service uptime percentages. Compare GitHub Actions, Copilot, and API uptime over the last 90 days. If you're evaluating GitHub's reliability for a new project or vendor review, this is now your starting point.

Next time GitHub declares an incident, note the severity level. If it's Degraded Performance, test whether your workflows are actually impacted before escalating. If it's a Copilot AI Model Providers incident, check which models are affected in the incident details and switch models if needed. The status page now gives you enough information to make that call without guessing.

For teams with automated incident response, update your alerting rules to handle the new Degraded Performance state differently from Partial Outage. You probably don't want the same PagerDuty escalation for both. Adjust your runbooks to reflect the new three-tier system.

The Bottom Line

Use this if you rely on GitHub's status page for incident response, SLA tracking, or vendor accountability. The new classification system and uptime metrics give you the data you've been missing. Skip it if you don't monitor GitHub's status page or don't care about distinguishing between "slow" and "down" — but that's a small minority of teams running production workloads on GitHub.

The real risk here is complacency. GitHub adding transparency is good, but it doesn't fix the underlying availability issues that prompted these changes. The status page is clearer now, but that just means you'll see the problems more accurately. The opportunity is better decision-making: you can finally respond proportionally to incidents instead of treating every alert as a crisis. For teams managing uptime-sensitive workflows, that's worth the effort to update your monitoring and runbooks.

Source: GitHub Blog