Is Docker Hub Down? How to Check Docker Hub Status in Real-Time

Is Docker Hub Down? How to Check Docker Hub Status in Real-Time

Quick Answer: To check if Docker Hub is down, visit apistatuscheck.com/api/docker-hub for real-time monitoring, or check the official status.docker.com page. Common signs include docker pull failures, rate limiting errors (429), authentication failures, push timeouts, "manifest unknown" errors, and registry unavailable messages.

When your CI/CD pipeline suddenly fails or developers can't pull container images, every minute of Docker Hub downtime blocks deployments and halts development. Docker Hub is the world's largest container registry, serving billions of image pulls monthly for millions of developers and enterprises. Whether you're seeing authentication errors, rate limit blocks, or complete registry unavailability, knowing how to quickly verify Docker Hub's status can save critical troubleshooting time and help you implement fallback strategies immediately.

How to Check Docker Hub Status in Real-Time

1. API Status Check (Fastest Method)

The quickest way to verify Docker Hub's operational status is through apistatuscheck.com/api/docker-hub. This real-time monitoring service:

  • Tests actual registry endpoints every 60 seconds
  • Shows response times and latency trends
  • Tracks historical uptime over 30/60/90 days
  • Provides instant alerts when issues are detected
  • Monitors authentication and pull operations across multiple regions

Unlike status pages that rely on manual updates, API Status Check performs active health checks against Docker Hub's production registry endpoints, including authentication flow and manifest retrieval, giving you the most accurate real-time picture of service availability.

2. Official Docker Status Page

Docker maintains status.docker.com as their official communication channel for service incidents. The page displays:

  • Current operational status for all Docker services
  • Active incidents and investigations
  • Scheduled maintenance windows
  • Historical incident reports
  • Component-specific status (Registry, Hub Website, Authentication, Build Service)

Pro tip: Subscribe to status updates via email, RSS, or webhook on the status page to receive immediate notifications when incidents occur.

3. Test Docker Pull Command

The most direct way to verify Docker Hub availability is attempting to pull a known image:

# Pull a small official image
docker pull hello-world

# Check response time and errors
time docker pull alpine:latest

What to look for:

  • Timeout errors (operation exceeds 5-10 minutes)
  • Authentication failures despite valid credentials
  • Rate limit errors (429 Too Many Requests)
  • TLS handshake failures
  • "manifest unknown" or "repository not found" errors for existing images

4. Check Docker Hub Website

Visit hub.docker.com and verify:

  • Website loading normally
  • Search functionality working
  • Repository pages accessible
  • Login functionality operational
  • Tag listings displaying

Website issues often indicate broader infrastructure problems affecting the registry itself.

5. Monitor Your CI/CD Pipeline Logs

CI/CD systems are often the first to detect Docker Hub issues:

# GitHub Actions
Error: buildx failed with: ERROR: failed to solve: alpine:latest: 
failed to resolve source metadata for docker.io/library/alpine:latest

# GitLab CI
ERROR: error pulling image configuration: download failed after attempts=6: 
dial tcp: lookup registry-1.docker.io: no such host

# Jenkins
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. 
Is the docker daemon running?

Pipeline failures across multiple projects simultaneously often indicate Docker Hub issues rather than project-specific problems.

Common Docker Hub Issues and How to Identify Them

Image Pull Failures

Symptoms:

  • docker pull hanging indefinitely
  • "error pulling image" messages in CI logs
  • Timeout errors after 5-10 minutes
  • "TLS handshake timeout" errors
  • "connection reset by peer" messages

Common error messages:

Error response from daemon: Get "https://registry-1.docker.io/v2/": 
net/http: request canceled while waiting for connection

Error response from daemon: Get "https://registry-1.docker.io/v2/": 
dial tcp: lookup registry-1.docker.io on 8.8.8.8:53: read udp 
192.168.1.100:45678->8.8.8.8:53: i/o timeout

What it means: Docker Hub's registry servers are unreachable, overloaded, or experiencing DNS issues. This differs from rate limiting—the connection itself fails before authentication.

Rate Limiting Errors (429 Too Many Requests)

Docker Hub implements strict rate limits for anonymous and authenticated users:

Anonymous users: 100 pulls per 6 hours per IP address Free accounts: 200 pulls per 6 hours per user Pro/Team accounts: Unlimited pulls (in practice, soft limits exist)

Rate limit error message:

ERROR: toomanyrequests: You have reached your pull rate limit. 
You may increase the limit by authenticating and upgrading: 
https://www.docker.com/increase-rate-limit

How to identify: Rate limiting returns HTTP 429 status codes and includes retry headers. These errors occur even when Docker Hub infrastructure is fully operational—they're policy enforcement, not outages.

Authentication Failures

Symptoms:

  • docker login failing with valid credentials
  • "unauthorized: incorrect username or password" despite correct credentials
  • Authentication token expiration errors
  • CI/CD pipelines unable to authenticate

Common error messages:

Error response from daemon: Get "https://registry-1.docker.io/v2/": 
unauthorized: incorrect username or password

Error response from daemon: pull access denied for [image], 
repository does not exist or may require 'docker login'

What it means: Docker Hub's authentication service may be degraded. If multiple users experience this simultaneously with verified credentials, it's likely a Docker Hub issue.

Push Timeouts and Failures

Symptoms:

  • docker push operations hanging
  • Layer upload failures
  • "blob upload unknown" errors
  • "unexpected EOF" during push operations

Common error messages:

error parsing HTTP 408 response body: invalid character 'R' 
looking for beginning of value: "Request Timeout"

received unexpected HTTP status: 500 Internal Server Error

blob upload unknown: blob upload to this repository is not available

What it means: Docker Hub's storage backend or upload infrastructure is experiencing issues. Push operations are often more sensitive to performance degradation than pulls since they involve writes.

Manifest Not Found Errors

Symptoms:

  • "manifest unknown" for existing images
  • Tag resolution failures
  • "requested image not found" for verified tags

Error example:

Error response from daemon: manifest for alpine:latest not found: 
manifest unknown: manifest unknown

What it means: Docker Hub's manifest service (which maps tags to image digests) may be degraded. This can occur during partial outages where blob storage works but the metadata service doesn't.

Registry Unavailable Messages

Symptoms:

  • Complete inability to connect to registry-1.docker.io
  • DNS resolution failures
  • SSL/TLS certificate errors
  • CDN or load balancer errors (502/503/504)

Error examples:

Error response from daemon: Get "https://registry-1.docker.io/v2/": 
Service Unavailable

Error response from daemon: Get "https://registry-1.docker.io/v2/": 
dial tcp 34.205.41.174:443: connect: connection refused

What it means: Complete registry outage or network infrastructure issues between your location and Docker Hub's CDN endpoints.

The Real Impact When Docker Hub Goes Down

CI/CD Pipeline Failures

Docker Hub outages immediately block continuous delivery for organizations worldwide:

  • Build failures: CI jobs cannot pull base images to build upon
  • Deployment blockers: New container versions cannot be pushed
  • Test environment failures: Integration tests depending on image pulls fail
  • Rollback impossibility: Cannot deploy previous working versions

For a development team shipping 20 deployments per day, a 4-hour Docker Hub outage completely halts production releases and emergency hotfixes.

Development Velocity Impact

Individual developers and teams experience immediate productivity loss:

  • Cannot start new projects requiring base images
  • Local development environments fail to initialize
  • Docker Compose stacks won't start without cached images
  • Dockerfile development and testing blocked
  • Onboarding new team members impossible (can't set up environments)

Time calculation: If 50 developers lose 2 hours of productivity at $100/hour average cost = $10,000 in lost development time for a 2-hour outage.

Production Incident Response Blocked

Docker Hub outages during production incidents create cascading failures:

  • Cannot deploy emergency patches
  • Horizontal scaling fails (new containers can't pull images)
  • Disaster recovery blocked (cannot restore from different regions)
  • Container orchestrators (Kubernetes, ECS) cannot schedule new pods
  • Auto-scaling policies fail as new instances cannot start services

Critical scenario: Your production database has an issue requiring immediate rollback. If Docker Hub is down and you don't have images cached locally, the rollback is impossible.

Multi-Cloud and Kubernetes Cluster Issues

Modern cloud-native applications depend heavily on Docker Hub:

Kubernetes impact:

  • ImagePullBackOff errors across all nodes
  • Failed pod deployments
  • Rolling updates stuck in progress
  • StatefulSets unable to scale
  • CronJobs failing silently

Cloud platform impact:

  • AWS ECS tasks failing to start
  • Google Cloud Run deployments blocked
  • Azure Container Instances unavailable
  • DigitalOcean Apps platform deployments failing

Rate Limiting as an Outage

Even when Docker Hub is technically operational, aggressive rate limiting can function as an effective outage:

Anonymous rate limits hit when:

  • CI/CD systems share IP addresses (common in cloud CI)
  • Multiple developers behind corporate NAT
  • Kubernetes clusters with many nodes pulling simultaneously
  • Development teams using shared VPN endpoints

Example scenario: A GitLab CI runner with 50 concurrent jobs burns through the 100-pull limit in 6 hours instantly, blocking all builds for the next few hours—effectively an outage even though Docker Hub is "up."

Financial and Reputational Impact

Direct costs:

  • Wasted CI/CD compute time (paying for failed pipeline minutes)
  • Developer time spent troubleshooting (misattributed to application issues)
  • Emergency meetings and incident response overhead
  • Lost deployment windows for time-sensitive releases

Indirect costs:

  • Customer-facing deployments delayed
  • Security patches cannot be deployed promptly
  • Competitive disadvantage (competitors using alternative registries ship faster)
  • Engineering team frustration and morale impact

What to Do When Docker Hub Goes Down

1. Implement Registry Mirrors and Caching

Configure Docker daemon mirror:

// /etc/docker/daemon.json
{
  "registry-mirrors": [
    "https://mirror.gcr.io",
    "https://your-private-mirror.example.com"
  ],
  "insecure-registries": []
}

Restart Docker after configuration:

sudo systemctl restart docker

Set up a local registry cache:

# Run a local pull-through cache
docker run -d -p 5000:5000 \
  --restart=always \
  --name registry-cache \
  -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \
  -v /var/lib/registry:/var/lib/registry \
  registry:2

Configure Kubernetes to use mirror:

# /etc/containerd/config.toml (for containerd runtime)
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
  endpoint = ["https://mirror.gcr.io", "https://registry-1.docker.io"]

2. Use Alternative Container Registries

Don't depend solely on Docker Hub. Replicate critical images to multiple registries:

GitHub Container Registry (ghcr.io):

# Tag for GitHub Container Registry
docker tag myapp:latest ghcr.io/yourusername/myapp:latest

# Authenticate and push
echo $GITHUB_TOKEN | docker login ghcr.io -u yourusername --password-stdin
docker push ghcr.io/yourusername/myapp:latest

Update Dockerfile and CI to pull from GitHub:

# Instead of:
# FROM node:18-alpine

# Use GitHub Container Registry mirror:
FROM ghcr.io/yourusername/node:18-alpine

Amazon ECR Public Gallery:

# Pull public images from ECR
docker pull public.ecr.aws/docker/library/alpine:latest

# Push your images to ECR Public
aws ecr-public get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin public.ecr.aws

docker tag myapp:latest public.ecr.aws/yournamespace/myapp:latest
docker push public.ecr.aws/yournamespace/myapp:latest

Quay.io (Red Hat):

# Authenticate to Quay
docker login quay.io

# Push images
docker tag myapp:latest quay.io/yourusername/myapp:latest
docker push quay.io/yourusername/myapp:latest

Update CI/CD to use fallback registries:

# .github/workflows/deploy.yml
- name: Pull base image with fallback
  run: |
    docker pull node:18-alpine || \
    docker pull ghcr.io/yourusername/node:18-alpine || \
    docker pull public.ecr.aws/docker/library/node:18-alpine

3. Pre-Pull and Cache Critical Images

Pre-pull images during CI setup:

# .github/workflows/build.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Pre-pull critical images
        run: |
          docker pull alpine:latest
          docker pull node:18-alpine
          docker pull nginx:alpine
          docker images # Verify cached locally

Kubernetes DaemonSet to pre-cache images on all nodes:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-precache
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: image-precache
  template:
    metadata:
      labels:
        app: image-precache
    spec:
      initContainers:
      - name: precache
        image: docker:latest
        command:
        - /bin/sh
        - -c
        - |
          docker pull alpine:latest
          docker pull nginx:latest
          docker pull your-critical-image:latest
        volumeMounts:
        - name: docker-socket
          mountPath: /var/run/docker.sock
      containers:
      - name: pause
        image: gcr.io/google-containers/pause:latest
      volumes:
      - name: docker-socket
        hostPath:
          path: /var/run/docker.sock

4. Authenticate to Increase Rate Limits

Even free Docker Hub accounts get 2x the pull rate of anonymous users:

# Authenticate in CI/CD
echo $DOCKER_PASSWORD | docker login -u $DOCKER_USERNAME --password-stdin

# Or use access token (more secure)
echo $DOCKER_ACCESS_TOKEN | docker login -u $DOCKER_USERNAME --password-stdin

GitHub Actions example:

- name: Login to Docker Hub
  uses: docker/login-action@v2
  with:
    username: ${{ secrets.DOCKERHUB_USERNAME }}
    password: ${{ secrets.DOCKERHUB_TOKEN }}

GitLab CI example:

before_script:
  - echo $DOCKER_PASSWORD | docker login -u $DOCKER_USERNAME --password-stdin

5. Build Local Base Images

Reduce dependency on Docker Hub by maintaining your own base images:

# Store in your private registry instead of pulling from Docker Hub
FROM your-registry.example.com/alpine:latest

# Or use alternative registries
FROM public.ecr.aws/docker/library/alpine:latest

Multi-stage builds to minimize pulls:

# Build stage - happens once
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production

# Runtime stage - reuses cached builder
FROM alpine:latest
RUN apk add --no-cache nodejs
COPY --from=builder /app/node_modules ./node_modules
COPY . .
CMD ["node", "server.js"]

6. Monitor Docker Hub Status Proactively

Set up automated monitoring:

#!/bin/bash
# check-docker-hub.sh
# Run via cron every 5 minutes

IMAGE="hello-world:latest"
TIMEOUT=30

if timeout $TIMEOUT docker pull $IMAGE 2>&1 | grep -q "Downloaded"; then
  echo "Docker Hub is operational"
else
  echo "Docker Hub pull failed - possible outage"
  curl -X POST https://your-alerting-endpoint.com/alert \
    -d '{"service": "docker-hub", "status": "down"}'
fi

Subscribe to alerts:

  • API Status Check - automated monitoring with instant alerts
  • Docker status page notifications at status.docker.com
  • Set up your own synthetic monitoring with Pingdom, Datadog, or Prometheus

7. Implement Retry Logic with Exponential Backoff

Shell script with retry logic:

#!/bin/bash
# docker-pull-retry.sh
IMAGE=$1
MAX_RETRIES=5
RETRY_DELAY=5

for i in $(seq 1 $MAX_RETRIES); do
  echo "Attempt $i of $MAX_RETRIES: Pulling $IMAGE"
  
  if docker pull $IMAGE; then
    echo "Successfully pulled $IMAGE"
    exit 0
  fi
  
  if [ $i -lt $MAX_RETRIES ]; then
    echo "Pull failed. Retrying in $RETRY_DELAY seconds..."
    sleep $RETRY_DELAY
    RETRY_DELAY=$((RETRY_DELAY * 2))  # Exponential backoff
  fi
done

echo "Failed to pull $IMAGE after $MAX_RETRIES attempts"
exit 1

Use in CI/CD:

- name: Pull image with retry
  run: ./scripts/docker-pull-retry.sh node:18-alpine

8. Post-Outage Recovery Actions

Once Docker Hub service is restored:

  1. Verify image integrity: Re-pull critical images and validate checksums
  2. Clear failed builds: Retry failed CI/CD pipelines
  3. Update cached images: Refresh local registry caches with latest versions
  4. Review rate limit status: Check if you hit rate limits during outage
  5. Document incident: Record downtime duration, impact, and lessons learned
  6. Update monitoring: Add checks for any new failure modes discovered
  7. Review fallback effectiveness: Did your alternative registries work? Improve configuration if needed

Related Infrastructure to Monitor

Docker Hub issues often correlate with other service disruptions. Monitor these related services:

Frequently Asked Questions

How often does Docker Hub go down?

Docker Hub maintains strong uptime, typically above 99.9% availability, but experiences 5-10 notable incidents per year affecting users globally or regionally. Partial degradations (slowness, specific region issues) occur more frequently. Rate limiting blocks many users daily even when the service is technically "up," which can feel like an outage.

What's the difference between Docker Hub being down vs rate limited?

Down: The registry infrastructure is unavailable—DNS fails, servers don't respond, authentication systems are offline. No amount of retrying will work until infrastructure is restored.

Rate limited: The service is fully operational but refusing your requests due to policy limits (100 pulls/6hrs anonymous, 200 pulls/6hrs free account). Authenticating with paid accounts or waiting for rate limit reset resolves this.

Can I use Docker Hub for production deployments?

Many organizations do, but best practices include: (1) Mirror critical images to private registries (ECR, GCR, ACR), (2) Use Docker Hub primarily for development and CI/CD, (3) Implement fallback registries, (4) Pre-cache images on production nodes, (5) Subscribe to paid Docker Hub plans for higher rate limits and SLA commitments.

How do I check if I'm rate limited?

Look for HTTP 429 status codes and error messages containing "toomanyrequests" or "rate limit." Check your current rate limit status:

TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token)
curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest

Look for RateLimit-Remaining header in response.

What are the best alternative container registries?

For private images:

  • AWS ECR (Amazon Elastic Container Registry) - tight AWS integration
  • Google Container Registry (GCR) - strong Kubernetes integration
  • Azure Container Registry (ACR) - best for Azure deployments
  • Harbor - self-hosted, open source, full-featured

For public images:

  • GitHub Container Registry (ghcr.io) - free, unlimited bandwidth
  • Quay.io - Red Hat backed, strong security scanning
  • AWS ECR Public - free public registry from Amazon

Should I pay for Docker Hub Pro or Team plans?

Consider paid plans if:

  • You're hitting rate limits regularly (check error logs)
  • You run large CI/CD operations (many concurrent builds)
  • You need unlimited pulls for development teams
  • You want SLA guarantees for business operations
  • You use private repositories extensively

Alternatives to consider:

  • GitHub Actions includes higher Docker Hub rate limits
  • Cloud provider registries (ECR, GCR, ACR) often include generous free tiers
  • Self-hosted Harbor for complete control

How do I prevent CI/CD failures from Docker Hub issues?

Essential strategies:

  1. Authenticate CI runners (2x rate limit increase)
  2. Use registry mirrors or pull-through caches
  3. Pre-pull base images at job start
  4. Implement fallback to alternative registries (ghcr.io, ECR Public)
  5. Cache Docker layers between builds
  6. Use paid Docker Hub plans for production CI
  7. Monitor Docker Hub status proactively

Does Docker Hub have regional outages?

Yes. Docker Hub uses CDN endpoints and regional infrastructure. An outage in US-East might not affect European users. If you suspect a regional issue, test from different geographic locations or use VPN to check other regions. The API Status Check monitors from multiple regions to detect location-specific problems.

What should I do if 'docker pull' is stuck or hanging?

Immediate actions:

  1. Cancel the pull (Ctrl+C) and try again
  2. Check Docker Hub status at status.docker.com
  3. Try pulling a different image (e.g., docker pull hello-world) to isolate if it's image-specific
  4. Check your network connection and firewall rules
  5. Clear Docker's DNS cache: sudo systemctl restart docker
  6. Try specifying a different registry mirror in /etc/docker/daemon.json
  7. If persistent, pull from an alternative registry (ghcr.io, quay.io)

How can I test if Docker Hub authentication is working?

# Test authentication
docker login

# Verify with a pull that requires auth (your private image)
docker pull yourusername/your-private-repo:latest

# Or check token validity
curl -u "username:password" "https://auth.docker.io/token?service=registry.docker.io&scope=repository:library/alpine:pull"

Successful authentication returns a JSON token. Failures return 401 Unauthorized.

Stay Ahead of Docker Hub Outages

Don't let container registry issues block your deployments and CI/CD pipelines. Subscribe to real-time Docker Hub alerts and get notified instantly when issues are detected—before your builds fail.

API Status Check monitors Docker Hub 24/7 with:

  • 60-second health checks testing real pull operations
  • Authentication flow monitoring
  • Instant alerts via email, Slack, Discord, or webhook
  • Historical uptime tracking and incident reports
  • Multi-region monitoring (US, EU, APAC)
  • Rate limit detection and alerting

Start monitoring Docker Hub now →


Last updated: February 4, 2026. Docker Hub status information is provided in real-time based on active monitoring. For official incident reports, always refer to status.docker.com.

Monitor Your APIs

Check the real-time status of 100+ popular APIs used by developers.

View API Status →