In Testcontainers, when do you pick Wait.forLogMessage over Wait.forHttp or Wait.forHealthcheck?

## What a wait strategy is for `start()` returns when Testcontainers considers the container *ready*, not merely created. Everything downstream — the first query, the first HTTP call — assumes that readiness definition is correct. A strategy that returns too early converts a startup race into a mysterious connection error inside a test; one that never returns converts it into a timeout. Strategies live in `org.testcontainers.containers.wait.strategy`, and the `Wait` class is the factory. You attach one with `waitingFor(...)`. ## The default A `GenericContainer` with exposed ports uses a port-listening strategy: it waits until the exposed ports accept connections. That is the cheapest signal and it is correct for a surprising number of images — but only when the process binds its port *after* it is able to serve. Servers that bind first and then load data, run migrations, elect a leader or build an index will accept a TCP connection well before they can answer a request. That mismatch is the classic source of a flaky first assertion. ## Wait.forLogMessage(regex, times) Best when the image prints an unambiguous readiness line and offers nothing better. Two details decide whether it works: - **The regex is matched against the whole line**, which is why every real-world example is wrapped in `.*` on both sides. A bare substring silently never matches, and you get a timeout instead of a wait. - **`times` counts occurrences.** Images with an initialisation phase emit their readiness banner more than once. Postgres is the standard example: the entrypoint starts a temporary server to run initialisation, then restarts for real, so waiting for one occurrence returns while the temporary server is being shut down. Its weakness is brittleness — the message is not a contract, and it can change between image versions. ## Wait.forHttp(path) Best for anything that serves HTTP and has a readiness or health endpoint. It polls the path through the container's mapped port and, by default, targets the first exposed port; `forPort(8080)` disambiguates when several are exposed. `forStatusCode(200)` sets the accepted code, and `forStatusCodeMatching(...)` takes a predicate when the service returns, say, any 2xx. It is the most semantically honest strategy when the endpoint genuinely reflects readiness rather than liveness — if `/health` returns 200 before dependencies are wired, you have simply moved the lie. ## Wait.forHealthcheck() Delegates to Docker's own health state, which is populated by the `HEALTHCHECK` instruction baked into the image. Where the image author has already encoded readiness, this is the least brittle option, because you inherit their definition instead of guessing. The hard precondition is that the image must declare a healthcheck — if it does not, the container never reports healthy and the strategy cannot succeed. ## Timeouts and retries Every strategy has a startup timeout (60 seconds by default in current versions), raised with `withStartupTimeout(Duration.ofMinutes(2))` on the container. That is the right knob for a genuinely slow image or a loaded CI agent. `withStartupAttempts(int)` is a different knob: it retries the whole container start when the strategy fails, which helps with genuinely flaky infrastructure and hurts when it masks a wrong strategy behind three slow failures. ## Combining and customising Strategies compose through `WaitAllStrategy`, useful when a container is ready only when two conditions hold — a port is listening *and* a log line has appeared. And `WaitStrategy` is an interface, so a container with an idiosyncratic readiness protocol can implement its own check rather than approximating it with a sleep. ## Module containers The preconfigured module containers ship with a strategy their maintainers chose — a database module knows how its server announces readiness. Overriding it is occasionally right (a custom image, an unusual entrypoint) but is more often a sign of a different underlying problem. ## Anti-patterns A `Thread.sleep` after `start()` is the tell that the readiness question was never answered: it is simultaneously too slow on a fast machine and too short on a loaded one. Retrying the assertion in the test is a second-best fallback that hides the real signal. Choose the strategy that describes readiness, then make its timeout generous.