Is GitHub Actions down, or is it your workflow?
A run is stuck or failing and nothing in your code changed. Before you start debugging, spend a minute finding out whether GitHub is having a bad day. Here’s how to check, what an outage looks like from inside a run, and what to do once it’s over.
The short version
- Check the Actions row on githubstatus.com.
- If it’s green, look at where the run broke. A failure inside your own commands is almost always yours.
- If it’s an outage, wait for it to clear, then re-run the failed jobs. Runs that never started may need a fresh push.
Step 1: check GitHub Status
GitHub Status lists each service separately, and Actions has its own row, so a problem with Git operations or Pages doesn’t have to mean your workflows are affected. Open incidents are listed at the top with updates as GitHub investigates.
The page is built on Statuspage, which has a public JSON API. This prints the current state of the Actions row:
curl -s https://www.githubstatus.com/api/v2/components.json \
| jq -r '.components[] | select(.name == "Actions") | .status'You’ll get operational, degraded_performance, partial_outage or major_outage. Status pages are updated by people, so the first minutes of an incident can still read operational. If the page is green but the signs below all point to GitHub, give it a few minutes and check again.
Step 2: read the run
Where and how a run fails usually tells you who broke it.
| Probably GitHub | Probably your workflow |
|---|---|
| Jobs sit in Queued for a long time and never get a runner. | A step that runs your commands fails with a real error: a test, a build, a lint. |
| A push or pull request doesn’t start a run at all. | It fails the same way when you re-run it. |
| Steps GitHub provides fail before your code runs: checking out, downloading actions, restoring a cache, uploading an artifact. | Only one workflow or one branch is affected. |
| Unrelated repositories break at the same moment. | You recently changed the workflow file, a dependency version or a secret. |
One case looks like an outage but isn’t one. GitHub documents that scheduled workflows can start late when load is high, especially at the top of every hour, and that some queued jobs may be dropped then. If your schedule runs are late but everything else is fine, move the cron off minute zero.
What happens to runs during an outage
GitHub doesn’t hold runs forever. If Actions is unavailable and a run hasn’t been queued within 30 minutes of being triggered, it’s discarded. A run that was queued but not picked up by a GitHub-hosted runner within 45 minutes is discarded too. So after a long outage, some commits may have no run at all. Nothing will retry them for you.
Step 3: recover once it’s over
- Find the runs that failed while GitHub was down:
gh run list --status failure --limit 20. - Re-run just the failed jobs, from the run page (Re-run jobs → Re-run failed jobs) or with
gh run rerun RUN_ID --failed. - For commits that never got a run, start one again. Use Run workflow if the workflow has a
workflow_dispatchtrigger, or push a new commit.
Spot it faster next time
GitHub Status has a Subscribe to updates button, so incidents can come to you instead of you going to the page.
An outage is also easy to spot when you can see all your workflows at once. ShipBoard keeps the workflows you pick in the macOS menu bar: amber while queued or running, red for a failure, a timeout or a startup failure. When every repo turns amber and stays there, or several go red at the same moment, it’s GitHub. When one goes red on its own, it’s time to open the logs. It’s free, and there’s a guide to other ways to see every repo at once.