Docker's healthcheck defaults make a ready container wait almost half a minute

The post argues that Docker's defaults are tuned for safety, not speed, and that every timing field should be set explicitly ^[14]. The delay comes from scheduling. Under the defaults it lists, the first probe fires one full interval after the container starts, and that interval is 30 seconds ^[1][2]. A check that would pass on its first run still has to wait for that run. The defaults also set the timeout equal to the interval, at 30 seconds each ^[2]. The example config puts the fix in a comment on the config line, `timeout: 3s # keep well below interval`, next to a 15-second interval ^[5]. That makes the timeout one fifth of the interval ^[2].

start_interval is what removes the wait for the first probe, but its scope is limited. It only applies while the container is inside start_period, so setting it on its own does nothing ^[3]. With no start period, the default startup rate is one probe per 30 seconds. The example's 2-second start_interval probes 15 times as often ^[1]. The post wants each of those probes to answer one question: can this process serve requests. Its probe checks only in-process state: the server is listening, migrations have finished, required caches are loaded ^[19]. Dependency checks go to a separate diagnostic endpoint that monitoring calls ^[19].

The half-minute figure only carries over to your service under one condition. The app has to be ready well before the first default probe would have fired ^[2]. The time saved is roughly 30 seconds minus the app's real time to ready. It drops toward zero as warmup approaches 30 seconds ^[4].

Health status only keeps traffic off a cold container if something acts on it. In the post, that is either a proxy that honors health status or Compose ordering through depends_on with condition: service_healthy ^[7][11]. The post says fixed waits like sleep 20 are either too long or too short, and the health gate replaces them ^[11]. It blames both of its opening failures on healthchecks that are misconfigured or missing. One is a 502 from a container still warming its caches. The other is a pipeline waiting two minutes on a container that was ready in ten seconds ^[15].

The exec form is the portable way to write the test. A JSON array after CMD runs the binary directly, while a plain string goes through /bin/sh ^[9]. Distroless images sometimes ship without a shell ^[8]. The post's preferred test is a subcommand built into the app's own binary, `["/app/api", "healthcheck"]` ^[18]. In my view this is the right design. The check ships inside the binary it tests, so it cannot go missing from the image. Two smaller traps remain. localhost can resolve to IPv6 ::1 while the app listens only on IPv4, so the post probes 127.0.0.1 ^[10]. When a Dockerfile has several HEALTHCHECK instructions, only the last one takes effect ^[13].

The post gives two outcomes for engines too old for start_interval: they may reject the field or ignore it ^[4]. Rejection is the better of the two. An ignored field raises no error, so the faster startup probing can disappear without anyone noticing. The post tells readers to check the defaults against the official HEALTHCHECK reference for their installed version ^[16].