GitHub down or not working? Check status before you change anything

Why the live status check belongs first

A broad service incident can make unrelated local-looking errors appear at the same time. A failed push may look like credentials. A queued job may look like bad workflow code. A Copilot sign-in loop may look like an extension problem. If the platform is degraded, changing all three can leave you with a second problem after GitHub recovers.

GitHub’s August 17, 2026 incident is a good example. GitHub’s final report says the event lasted 7 hours 47 minutes and affected GitHub.com, Issues, Pull Requests, APIs, Actions, Copilot, raw and archive downloads, and several organization authentication services. At the peak, GitHub reported roughly 20 percent errors for web and API traffic and about 50 percent for raw and archive downloads.

That incident is resolved. GitHub traced it to load-balancer saturation in its Central US infrastructure, a sidecar autoscaling policy that did not account for the right concurrency limit, and retry behavior that amplified traffic. Those facts explain one past incident; they do not explain every GitHub error today.

Match your symptom to the right GitHub surface

Write down the exact error, time, time zone, account, repository, client, and action. Then place it in one row before you troubleshoot:

• Website: github.com will not load, pages time out, or Issues and Pull Requests return errors.
• Git transport: clone, fetch, pull, or push fails over HTTPS or SSH while the website may still work.
• API or webhooks: a client, integration, webhook, or automation gets timeouts, rate responses, or authentication errors.
• Actions: a workflow does not trigger, stays queued, cannot reach a runner, or fails during one job or step.
• Copilot: chat, suggestions, token authentication, or one editor integration fails while other GitHub surfaces work.
• Raw files and downloads: release assets, source archives, raw content, packages, or dependencies fail while repository pages remain available.
• Organization access: SSO, SAML, OIDC, SCIM, Team Sync, policy, or one managed identity path is affected.

Two surfaces can fail for different reasons. Do not collapse a website timeout, a 403 from one private repository, and a skipped Actions job into one diagnosis without evidence.

Use status history, not just the green headline

Open the current component list and incident history. Record the component, incident update, and time. A page that is green now may show a recently resolved incident that overlaps your first failure.

If several unrelated GitHub surfaces fail across accounts, devices, or networks during an official incident, pause broad local changes. Preserve the exact error and retry after GitHub reports recovery. Then verify the real outcome rather than assuming the incident fixed every local issue.

If status is healthy and one narrow case still fails, continue. A green status page means GitHub is not reporting a broad known incident; it does not prove every account, repository, region, runner, client, or network path is healthy.

Compare scope without destroying evidence

Use the smallest safe comparisons available. Stop when one comparison narrows the problem.

• One public page versus all GitHub pages: if public pages fail too, the issue is broader than one private repository permission.
• Website versus git client: a working website with failed fetch or push keeps attention on transport, credentials, repository access, client state, or the local network path.
• One repository versus another authorized repository: one-repository scope can point toward permissions, repository state, rules, or a remote URL without proving any one cause.
• One account versus another authorized account: use only accounts you are allowed to test. Do not share tokens or borrow credentials.
• One browser profile versus a private window: this can separate a profile, cookie, or extension path without proving which item is responsible.
• One trusted network versus another: this can reveal a firewall, proxy, DNS, ISP, captive portal, or managed-network branch. Consider data cost and policy first.

On a work, school, or managed device, do not bypass the firewall, proxy, VPN, certificate inspection, SSO, or organization policy. Ask the administrator and keep a rollback plan.

If the website works but clone, fetch, or push fails

Record whether the remote uses HTTPS or SSH, the exact operation, and the full error with secrets and private paths redacted. Confirm that the repository URL is the intended one and that the account should have access.

GitHub’s connectivity guide separates firewalls, proxies, company networks, slow downloads, SSH and HTTPS paths, and its GitHub Debug tool. Comparing HTTPS and SSH can be useful when policy allows it, but do not replace a working remote URL or credential path casually.

A 401 or 403 is not automatic proof of a bad token. It can also involve repository access, SSO authorization, policy, the requested endpoint, or an account mismatch. Do not revoke credentials until the scope justifies it and you know how dependent tools will recover.

If GitHub Actions is the only failing surface

Open the workflow run and preserve the run URL, trigger, commit, job, failed step, queue time, runner label, and logs. Check whether the workflow triggered at all, was skipped by a condition or path filter, is waiting for a runner, or started and failed inside a step.

GitHub documents workflow logs, debug logging, trigger conditions, scheduled-workflow delays, runner state, and network checks as separate branches. A job stuck in queue does not justify editing working YAML. A failed step does not justify re-registering every runner.

After a platform incident resolves, rerun only when the preserved history and current status support it. Confirm the intended job actually completes; a click on “Re-run” is not the outcome.

If Copilot fails but the rest of GitHub works

Keep Copilot scope separate from the GitHub website and git transport. Record the editor or CLI, extension version, signed-in account, exact message, and whether another Copilot surface works.

GitHub’s Copilot CLI guidance separates missing credentials, revoked or insufficient tokens, policy denial, keychain access, and wrong-account states. Investigate those only after live status and the surface comparison stop pointing to a broader incident.

Do not paste private code, tokens, organization names, or authentication output into a public issue while testing. If the problem involves organization policy, use the organization’s approved support route.

If other services fail too, widen the network check

If GitHub, other websites, and unrelated apps all fail on the same Windows PC, this is no longer a GitHub-only problem. Use the Wi-Fi connected but no internet guide to separate device, router, DNS, captive portal, and wider connection scope.

If browser tabs or applications crash rather than returning GitHub errors, use the browser-crash guide. A process crash and a service response need different evidence.

Build a clean escalation package

When status is healthy but the failure is repeatable, a short evidence package is more useful than a list of everything you tried:

• exact error text, date, time, and time zone
• current GitHub status and any recent matching incident
• affected surface: web, git, API, Actions, Copilot, download, or organization access
• account and repository scope, described without private identifiers
• browser, git client, editor, extension, runner, or integration version
• HTTPS or SSH transport and whether another authorized path works
• device and network comparisons that were safe to perform
• workflow run URL, job, step, runner label, and redacted logs when Actions is involved
• every local change and the verified result

Review screenshots and logs before sending them. Remove tokens, private keys, secrets, email addresses, private URLs, machine names, source code, and organization details that support does not need.

Where OmniMend fits

After GitHub Status is healthy, OmniMend on a supported Windows or Apple Silicon Mac can help keep local network, process, storage, crash, client-version, and recent-change evidence together. It does not monitor GitHub’s private infrastructure, restore an outage, access private repositories, repair workflows, rotate credentials, or guarantee a fix.

Review what OmniMend can and cannot inspect or browse the evidence-first guide library. Keep source code, tokens, private repository details, and unreviewed logs out of anything you share.