Public | Automated Build

Last pushed: a year ago
Short Description
wait-for-it containerized
Full Description


Hi there! I wrote wait-for-it in order to help me orchestrate containers I operate at my day job. I thought it was a neat little script, so I published it. I assumed I would be its only user, but that's not what happened! wait-for-it has received more stars then all of my other public repositories put together. I had no idea this tool would solicit such an audience, and I was equally unprepared to carve out the time required to address my user's issues and patches. I would like to solicit a volunteer from the community who would be willing to be a co-maintainer of this repository. If this is something you might be interested in, please email me at Thanks!

wait-for-it is a pure bash script that will wait on the availability of a host and TCP port. It is useful for synchronizing the spin-up of interdependent services, such as linked docker containers. Since it is a pure bash script, it does not have any external dependencies.

Usage host:port [-s] [-t timeout] [-- command args]
-h HOST | --host=HOST       Host or IP under test
-p PORT | --port=PORT       TCP port under test
                            Alternatively, you specify the host and port as host:port
-s | --strict               Only execute subcommand if the test succeeds
-q | --quiet                Don't output any status messages
-t TIMEOUT | --timeout=TIMEOUT
                            Timeout in seconds, zero for no timeout
-- COMMAND ARGS             Execute command with args after the test finishes


For example, let's test to see if we can access port 80 on, and if it is available, echo the message google is up.

$ ./ -- echo "google is up" waiting 15 seconds for is available after 0 seconds
google is up

You can set your own timeout with the -t or --timeout= option. Setting the timeout value to 0 will disable the timeout:

$ ./ -t 0 -- echo "google is up" waiting for without a timeout is available after 0 seconds
google is up

The subcommand will be executed regardless if the service is up or not. If you wish to execute the subcommand only if the service is up, add the --strict argument. In this example, we will test port 81 on which will fail:

$ ./ --timeout=1 --strict -- echo "google is up" waiting 1 seconds for timeout occurred after waiting 1 seconds for strict mode, refusing to execute subprocess

If you don't want to execute a subcommand, leave off the -- argument. This way, you can test the exit condition of in your own scripts, and determine how to proceed:

$ ./ waiting 15 seconds for is available after 0 seconds
$ echo $?
$ ./ waiting 15 seconds for timeout occurred after waiting 15 seconds for
$ echo $?


I wrote this script for my employer, Ginkgo Bioworks, who was kind enough to let me release it as an open source tool. We are always looking to hire talented folks who are interested in working in the field of synthetic biology.

Docker Pull Command
Source Repository