# Docker Hub status

> Is Docker Hub down? Live status for the container registry, uptime history, and per-region response times from our own probes every 2 minutes.

Published: 2026-08-23 | Canonical: https://yoping.me/status/docker-hub

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/docker-hub. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.