Startup probe failed: The container did not finish starting within the startup probe's budget

A startup probe gives a slow-starting container a long window to come up, during which liveness and readiness probes are suspended. If that window expires, the container is killed — so the failure means the application exceeded a deadline you set.

Applies to: Kubernetes 1.16 and later

What it means

The startup probe exists specifically to solve the slow-boot problem. While it is running, liveness and readiness probes are disabled, so an application that takes three minutes to load cannot be killed by a liveness probe at thirty seconds. The total budget is failureThreshold × periodSeconds, and when it is exhausted the kubelet kills the container just as a liveness failure would. So a startup probe failure has a specific meaning that is easy to misread: the application did not become healthy within a window you chose. The fix is either a longer window or a faster start, and deciding which requires knowing how long the application actually takes.

Most common causes

• The budget is genuinely too short — a JVM application loading a large context, a service warming a cache, a database performing recovery.
• The application is stuck during startup and would never have become healthy at any budget.
• The probe checks an endpoint that only becomes available after startup completes, creating a circular wait.
• A dependency needed at startup is unavailable, so initialisation never finishes.
• The container is CPU-limited so tightly that startup work is throttled to a crawl.
• The probe's port or path is wrong, so it could never have passed.

How to diagnose it

1. Measure the real startup time. Run the image outside the cluster, or read the application's own startup log timestamps.
2. Compute the configured budget: failureThreshold × periodSeconds. Compare it against the measured time with a wide margin.
3. Read the events: kubectl describe pod POD shows Startup probe failed followed by Killing.
4. Check the logs from the killed container with kubectl logs POD --previous to see how far initialisation got.
5. Check for CPU throttling — a container at its CPU limit during a compute-heavy start takes far longer than the same image on an unconstrained machine.

How to fix it

1. Raise failureThreshold rather than periodSeconds. A high threshold with a short period means the container is recognised as ready promptly once it is, while still tolerating a long worst case.
2. Give the container a higher CPU limit, or no limit, during startup if throttling is the constraint — the burst is short-lived.
3. Point the probe at an endpoint that becomes available early and reflects real readiness, not one that only exists after full initialisation.
4. Fix the underlying slow start if it is unbounded. A probe budget cannot compensate for an initialisation step that hangs.
5. Confirm the port and path are correct before assuming the budget is the problem.

Notes

A startup probe is the correct answer to the very common pattern of inflating initialDelaySeconds on a liveness probe. That delay applies on every restart and is a fixed guess; a startup probe adapts to how long the container actually takes and then gets out of the way.

Related

• Liveness probe failed — The container was restarted as unhealthy
• CrashLoopBackOff — Repeated restarts with increasing delay

Sources

• Kubernetes documentation — Configure Liveness, Readiness and Startup Probes
• Kubernetes documentation — Pod Lifecycle: container probes