github.com loading in your browser proves almost nothing. GitHub is a bundle of services that fail independently, the web UI, git over SSH and HTTPS, the REST and GraphQL APIs, Actions and its runner fleet, Pages, Copilot, webhooks, and the package registries. During most incidents the homepage stays reachable while one backend component degrades, so the useful question is never "is GitHub down," it is "which part of GitHub is down, and is it broken for everyone or just for me."
The parts of GitHub that fail separately ¶
- Web UI. github.com itself, repository pages, pull requests, issues. Served by front-end infrastructure that survives most backend incidents.
- Git operations. push, pull, fetch, and clone over SSH (git@github.com) and HTTPS. These hit different backends than the web UI, and SSH and HTTPS can fail independently of each other.
- API. The REST and GraphQL endpoints at api.github.com. CLI tools, CI integrations, IDE plugins, and bots all depend on these, so an API incident breaks tooling even when the website is fine.
- Actions. The workflow scheduler plus the hosted runner fleet. Actions incidents usually show up as queue delays first, jobs sitting in "queued" for many minutes, and only later as hard failures.
- Pages. Static hosting on *.github.io domains. Builds can fail, or already-published sites can stop serving, and those are two different failures.
- Copilot. Completions and chat run as their own service with their own incident history.
- Webhooks. Delivery of push, PR, and issue events to your systems. During a webhook incident, events arrive late or not at all, which silently stalls anything downstream that waits on them.
- Packages and registries. GitHub Packages and ghcr.io container pulls. A registry incident breaks builds that otherwise never touch GitHub.
Any one of these can have a bad hour while the rest work normally. GitHub's own status page tracks them as separate components for exactly this reason.
The reachability trap ¶
A plain reachability check against github.com is close to worthless during a typical GitHub incident. The homepage and most repo pages keep answering 200 OK while Actions queues back up, webhooks go quiet, or the API throws elevated errors. Curl the homepage and everything looks green; meanwhile your entire CI pipeline is stalled.
This is why the isitdown.io check for github.com shows two things side by side: the result of our 4 independent probe methods run in parallel against the site, and GitHub's official status feed from githubstatus.com. The probes tell you whether the front end is reachable and whether any specific request type is being blocked or mishandled; the status feed tells you whether GitHub has an open incident on a backend component that no external probe can see. When the probes all pass but the feed lists an Actions incident, you have your answer in one screen.
For an ongoing view, the GitHub publisher page polls GitHub's own Atlassian Statuspage feed every 5 minutes and shows live incidents by name, so you can watch an incident open, update, and resolve without refreshing githubstatus.com yourself.
Triage order: your repo, your org, or global ¶
- Reproduce outside the failing repo. Run the same operation against a different repository. If
git pushfails on one repo but works on another, the problem is that repo, a pre-receive hook, a size limit, a locked branch, not GitHub. - Reproduce outside your org. Expired tokens, SSO enforcement, and IP allow lists produce errors that look exactly like outages but only affect your organization. Cloning a public repo anonymously is a quick control test.
- Compare git errors with the UI. If the web UI loads the repo fine but
git pushover SSH times out, the incident is in the git backends or SSH specifically. Switch the remote to HTTPS as a cross-check:git remote set-url origin https://github.com/OWNER/REPO.git. If both git protocols work but the UI returns errors, it is the web tier. - Separate Actions delays from Actions failures. Jobs stuck in "queued" point at runner capacity or the scheduler. Jobs that start and then fail on checkout or artifact upload point at the underlying git or storage services. The distinction matters because a queue backlog clears on its own, while checkout failures will re-fail on retry.
- Check the feed. If /publisher/github lists an open incident naming the component you are stuck on, stop debugging your own configuration. It is them, not you.
If nothing reproduces and the feed is green, run the standard down-for-everyone-or-just-me diagnostic. Corporate proxies that block SSH on port 22 are a steady source of "GitHub is down" reports that are actually local policy.
Symptom to component ¶
| What you see | Likely component | What to do |
|---|---|---|
| Web pages return errors | Web tier | Check the feed; git and API often still work. |
| git push/pull hangs or is refused | Git backends (SSH or HTTPS) | Try the other protocol; check the feed. |
| API calls return 5xx | api.github.com | Back off; do not hammer retries. |
| Jobs stuck in "queued" | Actions scheduler / runners | Wait; do not cancel-and-rerun in a loop. |
| Pages site unreachable | Pages serving or build | Check whether the build failed or serving stopped. |
| Webhook-driven jobs never start | Webhook delivery | Check recent deliveries in repo settings; redeliver after recovery. |
| ghcr.io pulls fail in CI | Packages / registry | Rely on local caches; retry later. |
| Only your repo or org affected | Local configuration | Tokens, SSO, hooks, IP allow lists. |
What to do while GitHub is down ¶
- Defer deploys. If your deploy pipeline runs through Actions or pulls from GitHub, a mid-incident deploy can half-complete and leave you in a worse state than waiting an hour.
- Do not force-push retries. A push that times out may have partially or fully landed on the server side. Repeated force-pushes during an incident risk clobbering refs once things recover. Wait, then verify the remote state with
git ls-remotebefore pushing again. - Do not cancel-and-rerun Actions in a loop. Re-queuing during a backlog puts your job at the back of a growing line and adds load. Re-run failed jobs once, after the feed shows the incident resolved.
- Keep a mirror remote for critical CI. Git supports multiple remotes natively. A mirror on another host that you push to alongside GitHub means an incident never blocks an emergency fix. For pipelines that gate production, it is cheap insurance.
- Redeliver webhooks after recovery. Events dropped during an incident do not replay themselves. Repository and app settings let you inspect and redeliver recent deliveries once the incident closes.
One more distinction worth making: if GitHub breaks at the same moment as several unrelated services you use, suspect a shared-infrastructure cascade rather than a GitHub-specific incident. The AWS cascade field guide covers how one provider incident surfaces as a dozen seemingly separate outages.
FAQ ¶
Is GitHub down for everyone or just me?
Open /check/github.com. It runs 4 independent probe methods in parallel and shows GitHub's own status feed next to the results. All probes failing means a real front-end outage. Probes passing plus an incident on the feed means a backend component is down for everyone. Probes passing and a green feed means the problem is on your side, so run the local diagnostic.
Why does github.com load while Actions is failing?
Because they are different systems. The website is served by front-end infrastructure that stays up through most incidents, while Actions depends on a scheduler and a runner fleet with their own failure modes. A reachability check only exercises the front end, which is exactly why isitdown.io pairs probe results with GitHub's component-level status feed.
git push hangs but the website works, is GitHub down?
Possibly, the git backends can degrade independently of the web UI, and SSH and HTTPS paths can fail separately too. Switch your remote to the other protocol as a quick cross-check, then look at /publisher/github for an open incident on Git Operations. If the feed is green and both protocols fail only from your network, suspect a local firewall or proxy blocking port 22.
Should I re-run failed Actions jobs during an incident?
No. During a queue backlog, cancelling and re-running moves your job to the back of the line and adds load to a struggling system. Leave failed runs alone until the status feed marks the incident resolved, then re-run once. Jobs that failed on checkout or artifact steps will generally succeed on that single post-recovery retry.