DockerHub Rate Limit?

[hashcatHitman]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Actions Runner Image

Discussion Details

According to the GitHub docs:

Docker Hub normally imposes rate limits on both push and pull operations which will affect jobs on self-hosted runners. However, GitHub-hosted runners are not subject to these limits based on an agreement between GitHub and Docker.

I just tried to use a container image in a workflow for the first time (added in hashcatHitman/rust_project_template@62aca58), and it failed due to rate limiting.

I'm confused. Did I not set it up correctly?

[abraunegg]

I'm confused. Did I not set it up correctly?

Im am seeing this as well - started today ..

[pgoforth]

No, this just started happening about 30 minutes ago.

Docker Hub: 429 on manifest HEAD and 500/504 from auth.docker.io/token for GitHub-hosted runners

Since 21:04 UTC on 2026-10-09, docker build on GitHub-hosted runners (BuildKit) fails resolving FROM apify/actor-node-playwright-chrome:20. Four attempts, two parallel jobs each (UTC):

21:04:01 and 21:04:07: 429 Too Many Requests on HEAD registry-1.docker.io/v2/apify/actor-node-playwright-chrome/manifests/20
21:16:43: 429 (same). 21:16:53: 500 Internal Server Error on POST auth.docker.io/token
21:21:28: 429. 21:22:03: 504 Gateway Timeout on POST auth.docker.io/token
21:27:01 and 21:27:14: 504 Gateway Timeout on POST auth.docker.io/token

The same workflow passed earlier the same day. From a non-GitHub network, auth.docker.io/token returned 200 in about 0.08 s during the same window. status.docker.com showed "All Systems Operational".

Are GitHub Actions IP ranges being throttled or affected by an incident, and is there an ETA?

[abraunegg]

I'm encountering the same issue with GitHub-hosted Actions runners.

My repository, https://github.com/abraunegg/onedrive, uses fedora:latest as a job container and has done so successfully for an extended period.

Starting 9 October 2026, repeated workflow executions began failing during container initialisation with:

docker pull fedora:latest
Error response from daemon: toomanyrequests:
You have reached your unauthenticated pull rate limit.

I've reproduced this on GitHub-hosted Ubuntu 24.04 runners in both westus and westus3.

The failures occur before repository checkout or any application code executes.

I reported this to GitHub Support under ticket #4841952, but the ticket was closed without technical investigation, directing me to community support resources.

Given that GitHub's documentation states that public Docker Hub pulls by GitHub-hosted runners are exempt from Docker Hub pull-rate limits, this appears to warrant investigation by GitHub's Actions infrastructure team.

[mason-alex]

Can attest this is happening as well.

Edit, appears to be Docker issues right now.
https://downdetector.com/status/docker/

[abraunegg]

appears to be operational again ...

[iamyakay]

Your setup looks fine for the container pull. The log shows a GitHub-hosted runner in westus3 hitting the unauthenticated pull limit on all three attempts, before checkout or shfmt runs.

The other reports in this thread point to a wider issue affecting GitHub-hosted runners. Yours failed at 20:56 UTC, slightly earlier than the 21:04 failures reported above. The logs don't explain why the documented exemption wasn't applied.

You could try Docker Hub credentials under container.credentials as a temporary workaround. Adding docker/login-action to the steps won't help here because the job container gets pulled before those steps can run. Authentication also won't necessarily help with the auth.docker.io 500/504 errors others are reporting.

I'd include this run in the infrastructure report rather than change the workflow to fix this particular error.

[anis-mselmi]

Your workflow configuration does not appear to explain this failure. The log shows the runner being rate-limited while resolving the Docker Hub image, before the job steps run; the other replies in this thread indicate a broader Docker Hub/GitHub-hosted-runner incident around the same time. That is consistent with an external registry-rate-limit problem, not a problem with your container syntax. For resilience, authenticate Docker Hub pulls with registry credentials where appropriate, or mirror frequently used images in a registry you control. Also check https://www.githubstatus.com/ and Docker Hub status for an incident before changing the workflow.