What to Do When GitHub Is Down

When GitHub stops cooperating, pause the retries and preserve your local work. You can often keep coding, testing and reviewing a diff while the affected hosted feature recovers. The first useful decision is which part of your workflow actually depends on GitHub right now.

Check the official GitHub Status page for the relevant component and incident. If the cause is still uncertain, use Is GitHub down? to separate a provider problem from repository access, your network or a runner issue.

Stop thrashing and save the evidence

Do not keep clicking rerun, force-pushing or changing authentication settings. Save your editor buffers and inspect your working tree. Keep the failing command, error, timestamp and any run or request identifier in a short incident note.

List operations that may already be in flight. A deployment job can continue after you lose access to its log. A timed-out push deserves a remote check when connectivity returns, not a force push based on an assumption that nothing arrived.

Pause new automated attempts if they are producing noise or duplicating work. Keep the pause narrow and record who owns it. An outage is a poor moment to make unrelated repository or workflow changes.

Confirm the scope and tell the team

Compare the incident with your failed action. An Actions incident does not necessarily block Git operations, and a Packages problem may leave pull requests usable. If there is no matching notice, ask one teammate to reproduce the same operation before broadening the investigation.

Use a message like this, replacing the brackets with observations:

GitHub [component] is affecting [workflow]. We observed [error] at [time and timezone]. The official incident is [link], or confirmation is still pending. Please hold [specific action]. Continue with [available work]. [Owner] will post the next update at [time].

Send that through a working team channel. Agree on one person to follow the incident and one person to manage release state if those are different responsibilities. Everyone else should not need to refresh the same page.

Keep working in your existing clone

Review code, write tests, run the project's available checks and make local commits. Choose work that does not require fetching a new dependency or querying a remote service. Keep a note of checks you could not run so a later review does not mistake “not attempted” for “passed.”

If collaboration is urgent, use an already approved private channel to share a patch or a focused diff. Include its base commit and intended branch. Do not improvise a public mirror for private code, and do not assume another repository has all the same branch policies or secrets.

Avoid letting local branches drift for hours without a plan. Split work into reviewable commits and tell teammates which files you are touching. Once GitHub returns, fetch and compare before pushing or merging.

Handle Actions according to where it stopped

For queued jobs, check the incident scope and whether the required runner is available. A self-hosted machine can execute local commands, but it still needs GitHub's coordination to participate normally in Actions. Moving a job to another runner is useful only if the failed part is actually runner availability.

For started jobs, preserve logs and identify the last completed step. If tests ran locally, record that result separately from the missing CI result. Do not remove required checks merely to make a merge button available.

GitHub documents rerunning failed jobs or individual jobs. After recovery, prefer the smallest appropriate rerun. Inspect publish, migration and deployment steps first because repeating them may have effects beyond another test result.

Treat API, PR and Packages failures separately

If PR pages are unavailable, keep review notes locally with filenames and commit references. Post them once the discussion is usable. If the API is failing, slow or pause nonessential integrations rather than turning every failed request into an immediate retry.

For package downloads, keep existing dependencies and cached artifacts. Read the failing hostname before choosing a workaround. If the request reaches npm rather than GitHub Packages, follow the npm outage playbook.

For publishing, write down the intended package version, release tag and artifact. Once access returns, verify whether each exists before trying again. Do not bump a version just to get past an uncertain result; first establish what was published and whether downstream systems consumed it.

Recover in a controlled order

An operational banner is a reason to verify, not permission to restart everything at once. The status-page explanation covers why component recovery and your experience can differ.

1. Repeat one representative read, such as a fetch or PR load.
2. Compare local and remote branch state before pushing.
3. Inspect queued and running workflows, including attempts started before the outage.
4. Confirm deployments, published packages and other external effects at their destination.
5. Rerun only work that is missing or failed, keeping required reviews and checks intact.
6. Resume paused integrations gradually and watch their errors and queues.
7. Tell the team what is verified, what remains delayed and who owns any cleanup.

Keep a short record of the blocked work and the workaround that helped. The useful follow-up is often a better local test path or a clearer release checklist, not a second hosting platform installed in a hurry.

When the useful work is already covered

If you want an optional break during a qualifying official outage, join the Nines ping list. Nines is a tiny browser arcade that opens when supported developer tools actually go down. Degraded performance alone does not open it. Keep the incident owner and recovery plan in place before stepping away.