GitHub status

How we check GitHub

We watch github.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the site itself, the hostname your browser opens and your git client talks to over HTTPS, rather than a health path that can keep answering while the product behind it is unusable.

We also watch api.github.com as a separate monitor, on the same schedule and with the same confirmation rule. It has its own board above, because the two fail independently and one board reporting healthy says nothing about the other.

The API root is one of the few that answers an anonymous request with a plain 200 and a JSON index of endpoints, so it can be checked honestly without a token. That matters, because a monitor holding a credential eventually reports an expired token as an outage, and the point of this page is to measure GitHub rather than our own housekeeping.

What is GitHub?

GitHub is where most of the world's source code lives, and that sentence undersells how much of a working day depends on it. A team that only thinks of GitHub as a place to browse code will still find, during an outage, that pull requests cannot be merged, CI pipelines will not start, container images will not pull, dependency installs fail, and the deploy that was scheduled for that afternoon quietly does not happen. The site is the visible part. The parts that break your day are mostly invisible until they stop.

That breadth is what makes GitHub incidents unusual to diagnose. GitHub is not one service but a collection of them sharing a name: the web interface, the git transport that clones and pushes, the REST and GraphQL APIs, Actions, Packages, Codespaces, and Pages. They fail independently, and they fail in combinations that are not obvious from the outside. It is entirely normal for github.com to load instantly in your browser while every git push in your team hangs, or for the API to return errors while the web interface behaves as though nothing is wrong. Any single green light, including ours, is a statement about one path through the system rather than a verdict on the whole.

The second complication is timing. A git-transport problem does not announce itself. Builds do not fail, they queue. Developers do not see an error page, they see a command that has not returned yet, and the first instinct is almost always to blame the local network, the VPN, or a credential that might have expired. Teams routinely spend the opening stretch of a GitHub incident debugging themselves. An outside reading that says the site is answering slowly from several countries at once short-circuits that, because it is the one piece of evidence a developer cannot mistake for their own machine misbehaving.

There is also a knock-on effect worth planning for. Because so much tooling treats GitHub as always-available infrastructure, an incident propagates into systems that have no obvious connection to it. A Dockerfile that installs a package from a GitHub release, a Terraform module pinned to a git URL, a CI step that checks out a shared actions repository: each is a dependency on GitHub that nobody wrote down. When those fail together, the reported symptom is usually "the deploy is broken" rather than "GitHub is degraded", and the time between the two descriptions is where the real cost of the outage sits.

For most teams the practical response is not to avoid depending on GitHub, which is unrealistic, but to know quickly when it is the cause. That is the whole point of watching it from outside.

Frequently asked questions

Is GitHub down right now?

Check the boards above; there are two, one for github.com and one for api.github.com, each refreshed every couple of minutes from all five of our regions. A single region seeing trouble is not enough for either board to say down, a second region has to agree first.

Is the GitHub API down right now?

Check the second board above, which watches api.github.com as its own monitor. The site and the API fail independently often enough that GitHub tracks them separately on its own status page, so a healthy website is not evidence that your integration should be working.

Why can I load github.com but git push fails?

Because they are different paths through GitHub's infrastructure. The web interface is served separately from the git transport, and GitHub's own incident history is full of days where one degraded while the other stayed healthy. If the board above shows the site responding and your push still hangs, check the git operations component on GitHub's own status page, and try an SSH remote against an HTTPS one to see whether the failure follows the protocol.

Does a GitHub outage break my CI and deploys?

Usually yes, and often before anyone notices the site is slow. Most pipelines start by cloning a repository and many pull actions or packages from GitHub as well, so a git-transport incident stalls builds that have nothing else wrong with them. Queued jobs tend to pile up rather than fail outright, which is why a short GitHub incident can show up as a deploy backlog an hour after it is resolved.

GitHub Actions is stuck but the status page says all systems operational. What now?

Wait a few minutes and check again, because Actions incidents are frequently posted well after the queue starts backing up. GitHub's status page reflects what their engineers have confirmed and chosen to publish; a queue that is not draining is evidence in its own right. Comparing our reading of the site with what you see in your own Actions tab is usually enough to tell an account-level problem from a platform one.

How is this different from GitHub's own status page?

Their page reports what GitHub's engineers have observed from inside their infrastructure. This page reports what our probes measured from outside it, on a fixed schedule, whether or not anyone has posted an update yet. Read both during an incident; they answer different questions.