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 of every
check and the formula filled in with your numbers. No more guessing at interval × retries.
interval 30stimeout 10sstart-period 40sstart-interval uses interval defaultretries 3Worst case ≈ start-period + retries × (interval + timeout). Best case ≈ start-period + retries × interval. During the start-period, failing checks do not count.
- iWorst case: marked unhealthy after 2m 40s
Best case (checks fail instantly): 2m. The difference is roughly retries × timeout, spent waiting for slow checks to time out.
Computed in your browser from the documented behaviour — nothing is uploaded. How it’s computed →
What it shows
The math the docs leave to you
Best & worst case
Worst case assumes each failing check runs the full timeout; best case assumes it fails instantly. Your real number sits between.
Tick-by-tick timeline
Every probe drawn on a timeline — the ignored start-period checks, each counted failure, and the exact moment it flips.
start-period, decoded
Failing checks during the start-period don’t count. We show where counting begins and why a long grace delays detection.
Kubernetes mode
liveness / readiness / startup probes: initialDelaySeconds + (failureThreshold − 1) × periodSeconds + timeoutSeconds.
Config smells
Flags timeout ≥ interval (checks run back-to-back), no start-period / initialDelay, and retries = 1 hair-triggers.
Nothing leaves your browser
100% static page; pure client-side simulation of the documented behaviour. No backend, no upload, no logs.
Open methodology
Every rule, in the open
No mystery score. Here is exactly how the timing is simulated — so you can verify and trust the result.
- Docker — between checksThe monitor waits `interval` between checks (or `start-interval` during the start-period on Docker 25.0+). A check runs for up to `timeout` before it is treated as failed.
- Docker — start-periodChecks that start within the start-period do not count toward retries. Counting begins once the start-period has elapsed (a success during it also ends startup).
- Docker — unhealthyAfter `retries` consecutive counted failures, the container is marked unhealthy. Worst case ≈ start-period + retries × (interval + timeout); best case ≈ start-period + retries × interval.
- Kubernetes — timingThe first probe runs after initialDelaySeconds, then every periodSeconds; each takes up to timeoutSeconds. After failureThreshold consecutive failures the container is restarted (liveness) or de-registered (readiness).
- Worst vs best caseWorst case assumes every failing check uses the full timeout; best case assumes instant failure. The true value lies between.
- WarningsFlags timeout ≥ interval (checks run back-to-back), start-period / initialDelay = 0 (no startup grace), and retries / failureThreshold = 1 (hair-trigger).
Related dev tools: cronwell (cron schedules), unixstamp (timestamps), ratelimitlens (429 retry times).
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.