Is GitHub down?

Filter by component on Starter and up.

The panel above shows each GitHub component as reported on GitHub's official status page: Git operations, API requests, Actions, Issues, Pull Requests, Packages, Pages, Codespaces, Copilot and others. Each line shows the current state and when it last changed.

Which GitHub component is affecting you?

GitHub incidents are usually partial. Pushes may work while Actions runs are delayed. Knowing which component is listed helps you decide whether to wait or work around it.

Git operations. Clone, fetch, push and pull. If this is degraded, CI jobs that check out code may fail too, even if Actions itself is fine.

API requests. Affects the CLI, integrations, bots and anything that talks to GitHub programmatically. Deploy tools that read release data or post commit statuses may stall.

Actions. Workflows may queue for a long time, fail to start, or lose logs. Scheduled workflows can be delayed or skipped during busy periods, even without an incident.

Pull Requests and Issues. Pages may load slowly, comments may fail to post, or merges may not complete.

Webhooks. Delivery to your CI, chat or deploy system may be delayed. Delayed webhooks often arrive in a burst later, which can trigger a wave of builds.

Packages. Registry pulls for npm, container images and others may fail, breaking builds that depend on them.

Pages. Builds or serving of GitHub Pages sites may be affected.

Is it GitHub or your setup?

• Run git ls-remote against a public repository. If it fails, the problem is likely network or GitHub. If it succeeds, check your repository permissions and credentials.
• Check whether expired tokens or SSH keys are the issue. Error messages for auth problems can look like outages.
• For Actions, look at whether the run is queued or failed. Queued for a long time during an incident is GitHub. Failing at a specific step is more likely your workflow or a third-party action.
• Self-hosted runners depend on your machines. If only those fail, check the runner hosts first.

Working around a GitHub incident

• Hold merges to protected branches until Actions recovers, so you do not merge unchecked code.
• Deploy from a local build only if your process allows it and someone signs off.
• Use a mirror or cache for packages if builds pull dependencies from GitHub Packages.
• Pause automated retries that could create duplicate releases when webhooks arrive late.
• Tell your team in one channel so ten people do not debug the same thing.

Following GitHub with Outage Clock

Add GitHub to your vendor list and filter to the components you rely on. A team that only uses GitHub for code and Actions might follow Git operations, Actions, Webhooks and API requests. Alerts include the component name and the latest update from GitHub, and arrive in email, Slack or Teams. When GitHub marks the incident resolved, we send that too.

A note on scheduled workflows

GitHub documents that scheduled workflows can be delayed during periods of high load, and that very busy times like the top of the hour are more affected. A late nightly job is not always an incident. If a scheduled job must run, add a heartbeat check so you know when it does not.

Questions

How quickly do you pick up GitHub incidents?

We poll every 2 minutes on paid plans and every 5 on Free. GitHub decides when to post the incident.

Does this include GitHub Enterprise Server?

No. Enterprise Server runs on your own infrastructure and does not appear on the public status page.

Follow GitHub