The process is running. Is the application ready?
Reading Docker Compose startup conditions through a question raised by HealthOS configuration.
About 3 min read
On this page
A source-analysis note edited by the Codex assistant on 10 September 2026. This is not an account of an incident Nam experienced or evidence that Nam personally ran an experiment.
In HealthOS Compose at commit 5131987, the Core waits for a successful migration. The frontend instead waits for the Core’s health check. These conditions raise a small question: does a process appearing in a running list mean another component can already send it requests?
A service may need initialization time after its process starts. Docker documentation distinguishes startup ordering from waiting for a dependency to pass its health check. Docker startup-order guide.
← → Scroll sideways for more columns if needed. Focus the table to use arrow keys.
| Condition | Startup question |
|---|---|
service_started |
Has the dependency started? |
service_healthy |
Has its declared health check passed? |
service_completed_successfully |
Has the dependency task finished successfully? |
The short form of depends_on waits for startup. Its long form allows a suitable condition, such as a passing health check or a completed one-off task. The completion condition helps explain migration configuration; it is not a continuously running health check. depends_on reference.
Health is an additional container status. A probe can succeed while the process is alive, then fail on a later check. Retry counts, timeouts and initialization periods affect when the status changes. HEALTHCHECK reference.
The next thing to read is the check itself. HealthOS probes /health/ready on the Core; the endpoint’s name suggests its purpose, but its logic defines the scope. Configuration analysis alone cannot establish functioning sign-in, health data or AI.
An endpoint check should answer the corresponding question. In a portfolio, “readiness is configured” needs a source version; “this flow ran” needs an environment, input and observed result.
Health checks and restart policies have different roles. Docker describes restart policies in terms of containers stopping or exiting; a process that remains alive while readiness fails does not establish successful recovery. Docker restart policies.
Likewise, restart: true inside depends_on concerns dependency updates or restarts explicitly performed by Compose. It should not be interpreted as continuous request routing or synchronization of every client. Dependency restart semantics.
A two-service fixture can isolate the concept: let an application listen for HTTP before it is ready, record the client’s first request, then repeat while waiting for health. Finally, deliberately fail readiness while keeping the process alive and record what the client sees. This is an experiment design, not a HealthOS result.
What the source provides immediately is a better question. Separating process, probe and business flow makes the missing evidence visible before describing a system as ready.
- Docker Docs — Control startup and shutdown order in Compose — https://docs.docker.com/compose/how-tos/startup-order/
- Docker Docs — Compose depends_on reference — https://docs.docker.com/reference/compose-file/services/#depends_on
- Docker Docs — Dockerfile HEALTHCHECK reference — https://docs.docker.com/reference/dockerfile/#healthcheck
- Docker Docs — Start containers automatically and restart policies — https://docs.docker.com/engine/containers/start-containers-automatically/
- HealthOS — Production Compose configuration at commit 5131987 — https://github.com/siinn1706/NT208_HealthOS/blob/5131987c953d800e1c343cc7156be7554e4e498f/infra/docker/docker-compose.prod.yml