If GitHub is failing, first identify the action that stopped working. A queued Actions job, a failed push and a pull request that will not load are different problems. One can fail while the others remain available.
Open the official GitHub Status page and check the matching component and incident details. This article is a diagnostic guide, not a live availability report. Use the status page for current provider updates, then compare those updates with the specific failure you can reproduce.
Is GitHub down for everyone or just me?
Ask a teammate to try the same operation against the same repository, using their own authorized account. If possible, compare results from a different network. A failure shared by two people behind one company proxy could still be a network problem.
Check whether other repositories work. If one private repository fails while another loads, investigate access, organization policy and repository-specific behavior before declaring a platform outage. Do not paste private repository names, tokens or request headers into public outage threads.
Record the operation, error text, time and whether you used the browser, Git over SSH, Git over HTTPS or an API client. These details turn “GitHub is broken” into a report someone else can test. Preserve the original error before changing your configuration.
Which GitHub component matches the symptom?
GitHub's status page separates services including Git Operations, API Requests, Pull Requests, Actions and Packages. Use those names to locate relevant updates, then work through the symptom you actually have.
| What you see | What to compare |
|---|---|
| Fetch or push fails | Git Operations, network reachability and authentication. |
| Repository loads but a PR does not | Pull Requests, the affected repository and another authorized viewer. |
| Jobs remain queued | Actions, runner availability and the workflow's eligibility to run. |
| Automation receives errors | API Requests, response details and account limits. |
| Dependency or image download fails | Packages and the actual registry hostname in the log. |
A successful browser visit does not test Git transport. Equally, an API error does not tell you that the website is unavailable. Compare like with like before drawing a conclusion.
Why does Git work while the website fails?
Your existing local repository contains work that does not require a successful browser request. Inspecting a diff, creating a branch and committing locally are separate from pushing to a remote. That distinction matters when deciding what is blocked.
For a network check, use one ordinary read operation your team already uses, such as fetching the existing remote. Review the remote address locally first. Avoid replacing the remote, changing protocols and regenerating credentials together: you will no longer know which change affected the result.
A rejected push can also be a branch protection, permissions or history problem. Read the response. A clear policy rejection is different evidence from a connection timeout, even if both prevent your work from reaching GitHub.
Does a queued Actions job prove an outage?
No. Inspect where the workflow stopped. Was it triggered at all? Is a job waiting for a suitable runner, approval or another job? Did it start and fail while downloading a dependency from somewhere else?
A self-hosted runner is another system to check. Its process, network and available capacity can fail independently. Repeatedly rerunning the workflow will not explain why that runner is unavailable. If the log points at npm, use the npm diagnostic guide rather than assuming Actions caused the download failure.
Compare a previously working workflow and the official incident description. You are looking for matching symptoms across independent runs, not merely a red icon. Avoid launching extra deployment jobs just to see whether the queue has moved.
What do API and Packages errors tell me?
Keep the response status, error body and request identifier when available. Check whether the client is calling GitHub or a separate service. An integration can fail before it ever reaches GitHub, and a dependency install can contact more than one host.
For package problems, distinguish reading a package from publishing it. Check the registry address and whether the package is public or private. If a private package fails for one account, permissions or credentials deserve attention. Do not make a private package public as a diagnostic shortcut.
For automated writes, a timeout leaves uncertainty about completion. Inspect the destination before repeating the operation. Two issue comments or two release attempts are not a useful availability test.
Should I trust official status, Downdetector or social posts?
The official status page provides GitHub's incident scope and recovery updates. Downdetector and social posts can reveal that other users are reporting trouble, but they cannot establish the failing component or cause on their own.
Check report times, error details and whether people describe the same operation. A wave of login complaints is weak evidence for an Actions outage. Your own reproducible failure still matters when the headline is green; the status-page guide explains why those observations can disagree.
What does a partial outage mean for my repository?
It means the provider has described a narrower failure than total service loss. Read the incident for the actual boundary: a feature, region or subset of requests may be affected. It does not promise that your repository has a working alternative route.
Once the symptoms match an incident, stop broad troubleshooting and use the GitHub outage playbook. After an update says recovery is underway, retry the original read operation once, inspect queued jobs and confirm your own workflow works before telling the team it is clear.