Wait4X: Stop Guessing When Your Services Are Ready

You know the drill. Your app crashes on startup because a database or Redis instance isn't fully ready yet. You add a quick sleep 10 to your Docker entrypoint, cross your fingers, and pray it's enough. Then it fails again in production because the database took 12 seconds.

Wait4X fixes that. No more arbitrary sleeps, no more fragile retry logic. Just a lightweight zero-dependency tool that waits until a service is actually available before your app starts.

What It Does

Wait4X is a command line tool that blocks until a specified service becomes reachable. You point it at a host and port, and it will keep checking (with configurable intervals and timeouts) until the connection succeeds. Once it does, your app starts. Simple.

It supports a few common protocols out of the box: TCP, HTTP, Redis, MySQL, PostgreSQL, MongoDB, and more. You can even wait for multiple services at once, or chain checks one after another.

Key features:

• Zero dependencies. No Node, no Python, no weird system libraries. Just a single binary.
• Supports TCP, HTTP, Redis, MySQL, PostgreSQL, MongoDB, gRPC, and file-based checks.
• Customizable retry intervals, timeouts, and total wait durations.
• Works great in Docker, CI/CD pipelines, and Kubernetes init containers.
• Native support for Unix sockets and environment variable interpolation.

Why It’s Cool

The most obvious win is reliability. No more brittle startup scripts. But there’s more.

First, it’s genuinely lightweight. The binary is tiny (under 10MB), and because it’s written in Go, it starts instantly and uses almost no memory while polling. That matters when you’re running it in sidecar containers or tight Docker images.

Second, the configuration is clean. You can pass everything via CLI flags or environment variables. For example:

wait4x tcp mysql.example.com:3306 --interval 2s --timeout 30s

Or for HTTP health checks:

wait4x http http://api.local/health --status-code 200

You can also combine multiple checks in a single command, and Wait4X will wait for all of them to succeed before exiting.

Third, the error messages are actually helpful. If a check fails, you get why (connection refused, timeout, unexpected status code) instead of a cryptic exit code.

How to Try It

The easiest way is via the official Docker image:

docker pull wait4x/wait4x
docker run --rm wait4x/wait4x tcp postgres:5432

Or grab the latest binary from the releases page. No install required.

Here’s a real Docker Compose example:

services:
  app:
    image: myapp
    depends_on:
      - db
    entrypoint: ["sh", "-c", "wait4x tcp db:5432 && ./start-app"]
  db:
    image: postgres:15

Just replace ./start-app with your actual entrypoint.

For Kubernetes, drop it into an init container:

initContainers:
  - name: wait-for-db
    image: wait4x/wait4x
    args: ["tcp", "postgres-service:5432"]

Final Thoughts

Wait4X won’t change your life, but it will save you time and headaches. It does one thing well and stays out of your way. No config files, no DSL to learn, no hidden magic.

It’s the kind of tool you’ll reach for when you need something between a fragile sleep and a full orchestration layer. Perfect for local dev, CI, and production use cases where you just need a reliable “wait for it” mechanism.

Give it a try next time your app fails to start because a service wasn’t ready. It’s refreshing to have something that just works.

Shared by @githubprojects