What causes CrashLoopBackOff from a probe?

The classic cause is a liveness probe that fails before the app has finished starting, or one that checks a dependency. Kubernetes sees the failing liveness probe, kills the container, restarts it, the new container also fails the probe before it is ready, and you get a restart loop - CrashLoopBackOff - even though the app is fine. The fixes are a startup probe (or a generous initialDelaySeconds) to give slow starts time, and keeping dependency checks out of liveness.

What is the difference between liveness, readiness, and startup probes?

Liveness decides whether to restart the container - it should fail only when the process is broken and a restart would help. Readiness decides whether to send the pod traffic - it can fail temporarily (e.g. a dependency is down) without a restart, just removing the pod from the service. Startup gives a slow-starting app time to boot before liveness and readiness kick in, so a long boot is not mistaken for a crash.

Should liveness and readiness use the same endpoint?

No. Liveness should hit a simple endpoint that only reflects the process being up, with no dependency checks. Readiness should hit an endpoint that checks the dependencies the app needs to serve. Using one endpoint for both is the mistake that turns a database blip into a restart storm. Generate both endpoints with our healthcheck tool, then wire them into the probes here.

Free tool · Runs in your browser

Kubernetes probes that don’t CrashLoop.

The #1 cause of CrashLoopBackOff is a liveness probe that fails before the app finishes starting. Set your paths and timing and get correct liveness, readiness, and startup probe YAML for your Deployment — with the startup grace that stops the loop.

Container port

Liveness path

Readiness path

Typical startup time (seconds)

Add a startup probe (recommended for slow starts)

The probe that kills a healthy app

It’s one of the most confusing failures in Kubernetes: the app is fine, the logs look normal, and yet the pod keeps restarting. Almost always it’s the liveness probe firing during the boot window or checking a dependency — Kubernetes reads the failure as “dead,” restarts the container, and the cycle repeats into CrashLoopBackOff. The fix is structural: a startup probe to cover the boot, a liveness probe that only reflects the process, and a readiness probe for dependencies. Get those three right and the loop simply doesn’t happen.

Probes are the orchestrator’s version of supervision — restart what’s dead, route around what’s not ready. Whether that supervision runs in Kubernetes or on a server you own, the goal is the same: keep the thing running, correctly, without human babysitting. That’s the job a control plane is built around.

Related free tools

Deploy to your own serverPush-to-deploy, your box systemd service generatorKeep your app running Reverse proxy + HTTPSCaddy / nginx + HTTPS DNS records helperPoint your domain

All free tools →

Supervision, with or without the cluster.

Infraveil keeps your services running across the hosts you own — restart what’s dead, route around what’s not ready, and prove it with a tamper-evident record — the same outcome probes give you in a cluster, on infrastructure you control.

See how it works

Get the keep-it-running playbook

Probes, healthchecks, supervision, and recovery done right. No spam.