Docker · compose · Kubernetes probes
When does your container actually go unhealthy?
Paste a HEALTHCHECK, a compose healthcheck block, or a Kubernetes probe and get the
exact time-to-unhealthy (or time-to-restart) — best and worst case — with a tick-by-tick timeline and the formula filled in.
No more guessing at interval × retries.
The math the docs leave to you
Worst case = each failing check runs the full timeout; best case = it fails instantly. Reality sits between.
Failing checks during the start-period don’t count. We show where counting begins and why a long grace delays detection.
initialDelaySeconds + (failureThreshold − 1) × periodSeconds + timeoutSeconds, for liveness / readiness / startup probes.
Flags timeout ≥ interval, no start-period / initialDelay, and retries / failureThreshold = 1.
Why it matters
The rule everyone remembers — interval × retries — ignores the timeout and the start-period, so it’s usually
wrong. healthcheckpln simulates the documented Docker state machine and Kubernetes probe timing for a failing container and
draws every probe, so you can tune interval / timeout / retries / start-period without trial-and-error.
Open methodology, no black-box score, and nothing you paste is uploaded.
Frequently asked questions
What does healthcheckpln compute?
Paste a Docker HEALTHCHECK line, a compose healthcheck block, or a Kubernetes probe, and it tells you the exact time from a container starting to fail until it is marked unhealthy (Docker) or restarted (Kubernetes) — both best case and worst case — with a tick-by-tick timeline of every probe and the formula plugged in with your numbers. It runs entirely in your browser.
How long until a Docker container is marked unhealthy?
Roughly start-period + retries × (interval + timeout) in the worst case (each check runs for the full timeout before failing), and start-period + retries × interval in the best case (checks fail instantly). During the start-period, failing checks do NOT count toward retries; counting begins after it. healthcheckpln simulates the real state machine so you get the exact number, not just the rule of thumb.
Why does my container take so long to go unhealthy?
The two usual culprits: a long start-period (failures are ignored during it) and a timeout close to or larger than the interval (a slow check eats the whole interval, so detection is much slower than the interval suggests). Paste your config and the timeline shows exactly where the time goes — the tool also flags timeout ≥ interval and retries = 1.
What is the difference between start-period and start-interval?
start-period is the grace window after startup during which failing checks are ignored (so a slow boot is not counted as unhealthy). start-interval (Docker 25.0+) is how often checks run DURING that start-period — usually more frequently than the normal interval, so the container can be marked healthy quickly once it is ready. start-interval changes how often start-period probes run but not the time-to-unhealthy, since those probes do not count.
Does it support Kubernetes liveness/readiness probes?
Yes — switch to Kubernetes mode and paste a probe. It uses the documented timing: the first probe runs after initialDelaySeconds, then every periodSeconds, each taking up to timeoutSeconds; after failureThreshold consecutive failures the container is restarted (liveness) or removed from Service endpoints (readiness). Time to restart ≈ initialDelaySeconds + (failureThreshold − 1) × periodSeconds + timeoutSeconds.
Best case vs worst case — which is real?
Both bound reality. Worst case assumes every failing check runs for the full timeout (e.g. a hung dependency); best case assumes checks fail immediately (e.g. connection refused). Your real time-to-unhealthy sits between them, closer to worst case the slower your failing check is.
Is my data safe?
Completely — this is a static page and everything is computed in your browser. Nothing you paste is uploaded; there is no backend and nothing is logged.