Add Health Checks to a Docker Compose Setup

The agent clones the repository into its own cloud sandbox and reads every Compose file before it writes a healthcheck. In a collection like docker/awesome-compose there are 37 compose.yaml files and only 8 of them declare a healthcheck: the MySQL, MariaDB, Postgres and SQL Server samples, which pair it with depends_on: db: condition: service_healthy, and the Elasticsearch stack. The other 29 use the short depends_on list, which waits for a container to start, not for the service inside it to answer. nginx-golang-postgres/compose.yaml is the pattern the repository already likes: test: ["CMD", "pg_isready"], interval: 10s, timeout: 5s, retries: 5, and a backend that depends on service_healthy.

A health check can only call what is inside the image, so the agent reads each Dockerfile for the stage Compose actually runs. In nginx-golang, compose.yaml builds the backend with target: builder, which is golang:1.18-alpine, so BusyBox wget is there and wget -qO- http://localhost:80/ works against the chi handler in main.go; the final FROM scratch stage has no shell at all, and the agent says so rather than writing a check that would fail if someone switched the target. In react-express-mongodb, mongo:4.2.0 answers mongo --eval "db.adminCommand('ping')", and the backend runs on node:lts-buster-slim with no curl, so the check is node -e with an http.get against the router's GET / on port 3000. In flask-redis, redis-cli ping covers Redis and the python:3.10-alpine web container is probed with a one-line urllib.request.urlopen against port 8000.

For each service it writes a healthcheck with interval, timeout, retries and a start_period sized to how the image boots, then rewrites the short depends_on entries into the long form with condition: service_healthy where the dependency is a database or a cache, so proxy in nginx-golang waits for the backend to answer rather than for its container to exist. Services the repository marks as sharing a restart: always or on-failure policy keep it. The agent leaves ports, volumes, secrets and networks exactly as they are, since each sample's README.md quotes its compose.yaml and the diff should stay readable beside it.

Then it proves each change in the sandbox: docker compose up --wait in the sample's directory, docker compose ps to read every service as healthy, and docker compose down -v afterwards. A check that never turns healthy, such as a probe against a path the app does not serve, is fixed before the pull request; a service with no tool to probe and no reasonable sidecar is listed in the description as left alone, with the reason. The repository's README.md says the samples are for local development only, and the pull request keeps to that: the checks make up wait correctly, they are not a production monitoring design.

What comes back is a pull request with one commit per sample, each changing only that sample's compose.yaml: new healthcheck blocks and depends_on rewritten to the long form. The description is a table with the sample, the service, the probe command and the image it relies on, followed by the short list of services left without a check and the reason, such as a scratch image with no shell.

A reviewer reads the table against the Dockerfiles once, looking for a probe that would break if the build target changed, and checks that no sample's README.md now quotes a stale compose.yaml. Because the repository asks for signed-off commits in CONTRIBUTING.md, the reviewer also checks that each commit carries a Signed-off-by line before merging.

The transcript keeps every docker compose up --wait and docker compose ps with its output per sample, so a service that is reported healthy in the pull request can be traced to the run that showed it. A follow-up on the same session can tune a start_period that turns out too short on slower machines.

In the console, add an automation to the Project with this prompt and a linear trigger on linear.issue.labeled, filtered to the agent label. When someone labels an issue such as "backend starts before Postgres is ready in the Go sample", the trigger puts the issue after the prompt, the run scopes itself to the samples the issue names, and the pull request links back to it. Only label changes made by a person in your Rush org fire the trigger.

From a script, the same body goes to POST /o/{org}/sessions with the repository in resources; a request_id made from the issue id makes a retry safe. A key's webhook_url reports when a run that key started finishes, and the handler reads the pull request from data.session_url.

Health checks are easy to write and hard to trust: the probe has to exist in the image, the path has to be one the app serves, and the only proof is bringing the stack up and watching docker compose ps. The agent does that for every changed sample in its own sandbox, with Docker available and nothing else running, and keeps the output, so the pull request's table is a record rather than a promise.

Doing it across a repository of samples by hand means reading dozens of Dockerfiles for the stage that actually runs. The agent reads them all, applies the one pattern the repository already uses, and leaves a per-sample commit the maintainers can merge or drop one at a time.

What about images with no shell, like the scratch stage?

Will the samples' READMEs go out of date?

Does it add healthchecks to the proxy services too?

Can it do the same in my app's single compose file?