IONOS Container Registry image pushes and pulls failed with 504 Gateway Timeout

Symptoms

On 4 March 2026 customers of the IONOS Container Registry got 504 Gateway Timeout errors when pushing or pulling container images, and deployments that relied on the registry were blocked. The status page first reported an increased error count on the registry at 09:23 UTC, saying customers might be unable to pull images.

At 10:23 UTC the Container Registry team traced the problem to the underlying Kubernetes cluster that serves a subset of images.

Symptom Image pull failuresHigh error rate

Root cause

Trigger

A migration combined with a temporary capacity constraint placed two critical control plane components on the same proxy instance, despite anti-affinity rules; the shared proxy then reached its concurrent connection limit.

Detection

–

Remediation

• Rolled back a component of the Kubernetes control plane to an earlier version
• Provisioned additional proxy capacity
• Moved the affected control plane components onto separate proxy instances

Action items

• Redesign registry-to-API connectivity so each node uses its own local proxy
• Adjust alert thresholds to warn before proxy connection use approaches capacity
• Deploy more infrastructure clusters and redistribute registries so no cluster exceeds safe capacity, with automation that keeps balancing load

Lessons

–

Sources

• https://status.ionos.cloud/incidents/43dzb3rj4v9d · official-status · archived copy

Related cases

• IL-0379 InfluxDB Cloud queries in Azure West Europe slowed and timed out as storage pods fell behind and kept restartingInfluxData · 2026

  same root cause · shared Pod scheduling and placement

• IL-0464 IONOS Managed Kubernetes control planes went unreachable for minutes at a time as their shared etcd grew and fragmentedIONOS Cloud · 2026

  same root cause · shared Managed Kubernetes control plane and provider API

• IL-0100 PostHog's feature flags pods were packed onto Kubernetes nodes that were too small for their CPU requests, and CPU saturation above 90% caused three outages in ten days through Redis overload, connection pool exhaustion and slow queriesPostHog · 2025

  same root cause · shared Pod scheduling and placement

• IL-0182 Too few CoreDNS replicas on EKS were overloaded during traffic spikes, raising latency and cutting the network for task pods, and the over-provisioned, tightly spread CoreDNS pods added later blocked Karpenter consolidation이언철 · 2024

  same root cause · shared Pod scheduling and placement

• IL-0037 Image registry rate-limited a whole region after a crash-looping DaemonSet with imagePullPolicy Always pulled through three NAT instancesDatadog · 2019

  same root cause · shared Container registry and its credentials

• IL-0064 CPU-heavy pods packed onto one Google Cloud node drove it to kernel panics, and the crash moved from node to node until the site was downMoonlight · 2019

  same root cause · shared Pod scheduling and placement

• IL-0036 A reindex Job that kept failing exhausted one node after another until the whole cluster was downUniverse · 2017

  same root cause · shared Pod scheduling and placement

Check your cluster for this

For AI tools and scripts

• This case as JSON: https://incidentlib-api.benchlet.com/cases/IL-0465
• The cases most like it: https://incidentlib-api.benchlet.com/cases/IL-0465/similar
• MCP server (Streamable HTTP, no key): https://incidentlib-mcp.benchlet.com/mcp

The API needs no key. The MCP server offers search_incidents, get_incident, list_incidents, get_topic and vocab; both are explained on API and MCP.