Is GitHub down? How to tell, and what to do next

The fastest answer is the GitHub status page on isuptime, which reads GitHub's own feed every few minutes and says what it currently reports.

The more useful answer is that the question is usually the wrong one. GitHub publishes eleven separate components, they fail independently, and in the overwhelming majority of incidents only one of them is affected. "Is GitHub down" almost always turns out to mean "is the one part of GitHub I am standing on down" — and those have different answers at the same moment.

GitHub is eleven services wearing one domain name

Here is what GitHub actually reports on, each with its own status:

That last row is the most interesting thing on the list, and I will come back to it.

The practical consequence: Actions can be broken for hours while Git operations are perfectly healthy. That is not an edge case, it is the single most common shape of a GitHub incident. Look at the titles GitHub gives its own incidents — "Incident with Actions", "Incident with Webhooks", "Disruption with Login and Release Asset downloads" — and the pattern is obvious. They are scoped, because the failures are scoped.

So when the aggregate indicator is amber, the useful move is not to conclude GitHub is down. It is to find out which component, and then ask whether you were using it.

Reading the status page properly

GitHub reports through Statuspage, which grades incidents in three levels. They are worth knowing because they are not intuitive:

• Minor — degraded performance. Things are slow or a fraction of requests fail. Most GitHub incidents are this.
• Major — a component is substantially broken for a substantial number of people.
• Critical — broad, severe failure.

Two things this vocabulary hides.

"Degraded" can mean a lot of your requests are failing. A minor incident on API Requests might be a 5% error rate. If your CI makes two hundred API calls per run, a 5% error rate is not a slow afternoon — it is a pipeline that fails almost every time. The severity label describes GitHub's blast radius, not yours.

The clock starts when GitHub decides. Every self-reported status page has a gap between when something breaks and when a human declares an incident. That gap is usually minutes and occasionally much longer, and it is the reason your team noticed before the page turned amber. That is normal and not evidence of dishonesty — it is just what a self-published status page structurally is, which is a subject worth its own post.

Five failures that impersonate a GitHub outage

These account for most of the times the status page is green and you are still stuck.

1. Rate limiting. The REST API allows 5,000 requests per hour for an authenticated token and 60 per hour for unauthenticated requests from an IP. Hit either and you get 403s that look exactly like a broken API. Check for the x-ratelimit-remaining header before blaming GitHub — rate limits are never posted as incidents, because from GitHub's side nothing is wrong.

2. SSH versus HTTPS. Git over SSH (port 22) and Git over HTTPS (port 443) are different network paths that fail independently, and corporate networks block port 22 constantly. If git push hangs over SSH, try the HTTPS remote before concluding anything. A push that works one way and hangs the other is a network problem, not a GitHub one.

3. npm is not GitHub. GitHub owns npm, and they are still separate services with separate status pages. A failing npm install is an npm registry question, not a GitHub one, and the two go down at different times. GitHub Packages is the GitHub-hosted registry and is on GitHub's status page; the public npm registry is not.

4. Expired credentials. Personal access tokens expire. Deploy keys get rotated. SSH keys get removed when someone tidies up an account. All three produce authentication failures that arrive suddenly, affect only you, and feel exactly like an outage.

5. Copilot's upstream. This is what that eleventh component is for. Copilot runs on models from other companies, so a Copilot failure may be Anthropic's or OpenAI's rather than GitHub's. GitHub splits "Copilot" from "Copilot AI Model Providers" precisely so it can tell you which — and it is a genuinely unusual piece of honesty, because most vendors reselling someone else's model do not admit the dependency exists on their status page at all.

What still works when GitHub really is down

The thing people forget under pressure: Git is distributed, and GitHub is a remote.

Your entire repository history is on your disk. During a total GitHub outage you can still commit, branch, merge, rebase, git log, git diff, git bisect, git stash, and review anything already fetched. None of that touches the network. Work does not have to stop; only sharing does.

What actually stops:

• Pushing and pulling
• Anything that lives in the web UI — PR review, issues, discussions
• CI, if it runs on Actions
• Deploys triggered by webhooks

Three things worth having decided in advance:

Push to a second remote. git remote add a mirror somewhere else and a total GitHub outage costs you nothing but a flag. This takes thirty seconds on a good day and is impossible to arrange on a bad one.

Know whether your deploy depends on GitHub. Plenty of teams discover during an Actions outage that their production deploy path runs through a GitHub-hosted runner and there is no manual route. Find that out on a Tuesday, not during an incident.

Self-hosted runners fail differently. They are your machines, so an Actions control-plane incident can stop jobs being dispatched to them even though the runners themselves are idle and healthy. Conversely, when the incident is capacity on GitHub's hosted runners, self-hosted keeps working.

Is it GitHub, or is it just me?

A decision procedure that resolves this quickly:

1. Check the status page. If a component is flagged and it is the one you are using, you have your answer.
2. Try a different network. Phone hotspot, off the VPN. If it works there, the problem is between you and GitHub — corporate proxy, DNS, a blocked port — not GitHub.
3. Try a different protocol. SSH if you were on HTTPS, or the reverse.
4. Try a different repository. If one repo fails and another works, it is permissions or that repo, not the platform.
5. Check whether anything else is broken. If several unrelated providers are reporting problems at the same moment, the common cause is more likely to be upstream infrastructure — a CDN or a cloud region — than each of them independently having a bad day.

That last step is most of why isuptime reads 102 status pages on one schedule rather than one at a time. Shared timing across unrelated providers is real evidence of a common cause. It is never proof of one, and anybody who tells you otherwise during an incident is guessing.

Why GitHub outages feel worse than they are

A ninety-minute Actions incident does not delete ninety minutes of work. It deletes ninety minutes of work from every engineer who was mid-flow, plus the queue that piles up behind it, plus the deploys that did not go out, plus the hour afterwards when everyone re-runs failed jobs at once and the recovering system gets hit by a thundering herd of retries.

That is the real reason GitHub feels disproportionately painful when it breaks. It is not that it breaks often — by the standards of a service that size it does not. It is that it sits directly on the critical path of shipping, so its downtime converts into idle engineers at close to a one-to-one rate.

Which is also the argument for the boring preparation above. The cost of a GitHub outage is mostly determined before it starts, by whether anything you depend on has a second path.

---

Live GitHub status on isuptime is read from GitHub's own public feed on a fixed schedule and shows what GitHub is currently reporting, with the timestamp of the check. It is not an independent test of whether GitHub works for you — here is exactly what it can and cannot tell you.