1 minute read

waitfor is a semantic condition poller for shell scripts, CI pipelines, Docker entrypoints, Kubernetes init containers, and agent workflows. It blocks until the condition you asked for is actually true, then exits 0.

That sounds small, but it solves a common source of fragile automation: guessing when a dependency is ready. Sleeping for ten seconds is simple until the database takes eleven seconds, the API is accepting TCP but failing health checks, or a rollout has not become available yet.

The CLI supports checks for HTTP, TCP, Unix sockets, port ranges, TLS, SSH, S3, DNS, Docker, local processes, systemd, exec commands, files, globs, logs, and Kubernetes resources.

For an HTTP readiness check:

waitfor http https://api.example.com/health --status 200

For a database port and an API before running tests:

waitfor --timeout 10m \
  tcp localhost:5432 \
  -- http http://localhost:8080/health --status 200

For Kubernetes:

waitfor k8s deployment/myapp --for rollout --namespace prod

waitfor is helpful because it makes waiting explicit and observable. It has timeouts, polling intervals, all-or-any condition modes, consecutive success requirements, stable-for windows, and JSON output for automation. Instead of burying readiness logic inside a script, the script says exactly what it needs.

It works especially well with agents because agents often need to start services, run tests, and make decisions from command results. waitfor gives them a reliable checkpoint: wait for the service, file, log line, DNS record, or rollout, then continue only when the environment is ready. That reduces flaky retries and makes failures easier to explain.

Updated: