Auguste ROCA
03/03/2026, 10:17 AMreplication-job-18438-attempt-0 failed to start due to a transient error when pulling a container image from the public Docker Hub registry. The issue resolved itself automatically after Kubernetes retried the image pull.
Evidence:
- The pod initially reported an ImagePullBackOff status, which triggered the alert.
- Kubernetes events for the pod show the specific error: Failed to pull image "airbyte/destination-bigquery:3.0.16": ... unexpected status from GET request to <https://registry-1.docker.io>.
- A subsequent check with get_pod_details confirmed the pod is now in a Running state, indicating the image pull eventually succeeded.
Remediation:
1. No action is required. This was a transient, external issue, and the system's built-in retry mechanism worked as expected to resolve it.
2. The alert can be considered resolved.kapa.ai
03/03/2026, 10:17 AMabctl install, repeated ImagePullBackOff errors were traced to Docker Hub rate limiting and/or transient network issues when pulling Airbyte images, not to a problem with the images themselves. [ImagePullBackOff loop] Your description (intermittent failures, automatic recovery on retry, error coming from registry-1.docker.io) is consistent with that.
Given the sources, the best-supported guidance is:
• Treat these as transient registry/network issues unless they become persistent.
• If they start happening frequently or pods stop recovering, investigate:
◦ Docker Hub rate limits and credentials (using authenticated pulls reduced ImagePullBackOff in the referenced case). [ImagePullBackOff loop]
◦ Network/proxy/firewall behavior between your cluster and Docker Hub.
Based on the evidence you shared and the available docs, your “no action required, alert resolved” conclusion is reasonable. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.