Docker Hub status

How we check Docker Hub

We watch registry-1.docker.io from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the registry host that docker pull actually talks to, not the website where humans browse images. The two are separate systems, and the site being reachable tells you nothing about whether a build can fetch a base image, which is the failure that stops deployments.

What is Docker Hub?

Docker Hub is the default container registry, which makes it one of the most widely depended-upon pieces of infrastructure in software delivery. Most Dockerfiles begin with an image that lives there, most CI pipelines pull at least one, and most Kubernetes clusters will fetch from it the first time a node runs a workload. Very few teams have written down that they depend on it, and almost all of them do.

The failure mode is specific and worth being precise about, because Docker Hub outages produce a lot of unnecessary alarm. Running containers are unaffected. An image that has already been pulled to a host stays there, and nothing at runtime phones home to verify it. What stops is every operation that fetches an image: a deploy that starts new containers, an autoscaler bringing up a node with a cold image cache, a CI job building from a base image, a developer starting a project for the first time. Production keeps running. The ability to change production goes away, which is a different problem with a different urgency.

Rate limiting causes more disruption than outages do, and it is often mistaken for one. Anonymous pulls are limited by IP address, and shared addresses make that limit arrive far sooner than the numbers suggest. A CI provider running many builds from a pool of addresses, or an office behind a single NAT gateway, can exhaust the allowance without any single person pulling much at all. The resulting error is not a server failure, it is the registry declining politely, and the fix is authenticating pulls rather than waiting for anything to recover.

That pattern also explains why Docker Hub problems appear so inconsistently. One build fails while another succeeds on the same commit, because one runner had a warm layer cache and the other did not, or because they left from different addresses. This randomness sends people looking for a race condition in their own pipeline, which is a frustrating way to spend an afternoon.

The durable fix is to stop treating a public registry as always available. A pull-through cache or a private registry holding your base images turns a Docker Hub incident into something you read about rather than something that stops a release. It is modest infrastructure, it is usually justified the first time a deploy fails at the worst moment, and almost nobody builds it until then.

Frequently asked questions

Is Docker Hub down right now?

Check the board above; it reflects our own probes against the registry host from all five of our regions, refreshed every couple of minutes. That is the host your builds pull from, so it is the reading that matters when an image will not download.

My docker pull is failing with toomanyrequests. Is Docker Hub down?

No, that error is rate limiting rather than an outage. Anonymous pulls are limited per IP address, which catches CI runners and office networks hardest because many machines share one address. Authenticating your pulls raises the limit substantially, and for CI it is the standard fix rather than an optimisation.

Does a Docker Hub outage take my running containers down?

No. Containers already running keep running, and images already present on a host keep working, because nothing at runtime contacts the registry to check them. What breaks is anything that pulls afresh, which means new deployments, autoscaling that starts a node without a warm cache, and CI builds that fetch a base image.

Why did my deploy fail when nothing changed in my code?

Most often because a base image was pulled again and the registry was unavailable or rate limited at that moment. A Dockerfile that starts from a public image reaches out on every build unless the layer is cached, so a build that succeeded an hour ago can fail now with an identical commit. Pinning images by digest and caching layers reduces how often this can happen.

Should I mirror the images my builds depend on?

For anything where a failed deploy is costly, yes, and it is less work than it sounds. A pull-through cache or a private registry holding copies of your base images removes both the rate limit and the outage from your critical path. Most teams only consider it after a Docker Hub incident has stopped a release, which is a predictable and avoidable lesson.