--- title: "Wait for observable readiness instead of sleeping" description: "Poll the service or state the test actually needs, with a bounded timeout and useful failure output." url: https://starsling.dev/ci-playbooks/techniques/poll-readiness canonicalUrl: https://starsling.dev/ci-playbooks/techniques/poll-readiness --- # Wait for observable readiness instead of sleeping Poll the service or state the test actually needs, with a bounded timeout and useful failure output. ## How to choose an approach Compare the examples by repository setup, prerequisites, and risks before adopting one. Each company implemented this in its own environment; measure each change against your own baseline. - **[Mastra](https://starsling.dev/ci-playbooks/mastra#poll-indexing)**: Use it when Repeated waits dominate an eventual-consistency integration suite. Check before adopting: Validate content or version readiness and fail clearly on a deadline; a matching count alone can miss same-size updates. - **[Mastra](https://starsling.dev/ci-playbooks/mastra#query-readiness)**: Use it when Integration tests race database startup or wait through conservative startup delays. Check before adopting: Probe the actual operation required by tests and fail on timeout. Follow-up #15895 awaited asynchronous deletions exposed by faster storage. - **[Stripe](https://starsling.dev/ci-playbooks/stripe#wait-for-observable-state)**: Use it when Tests sleep for a fixed period before checking an asynchronous result. Check before adopting: Probe the capability the next step needs; an open port can come before migrations or workers are ready. Keep tests that intentionally verify timeouts unchanged. - **[Uber](https://starsling.dev/ci-playbooks/uber#protocol-readiness)**: Use it when Containers report healthy before the network interface used by the tests accepts connections. Check before adopting: Probe the same protocol, authentication and readiness condition the consumer uses, keep a bounded startup timeout with logs, and keep any retries until the new probe is proven. ## Apply this technique ````text Evaluate and apply this CI technique to my repository: Wait for observable readiness instead of sleeping. Poll the service or state the test actually needs, with a bounded timeout and useful failure output. Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/poll-readiness.md Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence. Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured. Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo. Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES. Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch. Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge. ```` ## How companies used this technique Read what each company changed and follow the original sources. ### Mastra: Poll the condition the test actually needs MongoDB vector tests replaced fixed sleeps with polling. Couchbase used its Search service ping for startup. Evidence: Source PR/commit evidence Use it when: Repeated waits dominate an eventual-consistency integration suite. Before applying it: Validate content or version readiness and fail clearly on a deadline; a matching count alone can miss same-size updates. [Read more in the Mastra playbook](https://starsling.dev/ci-playbooks/mastra#poll-indexing) [Primary source](https://github.com/mastra-ai/mastra/pull/13808) ### Mastra: Wait until the database answers a query StarSling’s agent replaced MSSQL’s TCP probe with sqlcmd SELECT 1 and let Compose --wait coordinate readiness. ClickHouse received a native query healthcheck too. This adapts the fixed-sleep recipe to semantic health checks and redundant polling. Evidence: Source PR/commit evidence Use it when: Integration tests race database startup or wait through conservative startup delays. Before applying it: Probe the actual operation required by tests and fail on timeout. Follow-up #15895 awaited asynchronous deletions exposed by faster storage. [Read more in the Mastra playbook](https://starsling.dev/ci-playbooks/mastra#query-readiness) [Primary source](https://github.com/mastra-ai/mastra/pull/14520) ### Stripe: Wait for readiness with a bounded poll Stripe sync-engine replaced fixed sleeps with a waitFor helper that polls a condition, returns as soon as it holds and throws when the deadline passes. Stripe Android’s UI test waits for a snackbar to hide only when it overlaps the element it needs to tap. Evidence: Source PR/commit evidence Use it when: Tests sleep for a fixed period before checking an asynchronous result. Before applying it: Probe the capability the next step needs; an open port can come before migrations or workers are ready. Keep tests that intentionally verify timeouts unchanged. [Read more in the Stripe playbook](https://starsling.dev/ci-playbooks/stripe#wait-for-observable-state) [Primary source](https://github.com/stripe/sync-engine-fork/pull/124) ### Uber: Wait for the connection the test actually uses SubmitQueue's MySQL healthcheck used localhost, which selected a Unix socket, while its clients connected over TCP and could start too early. The fix probes 127.0.0.1 and removes the second retry loop from test setup. OPT17 is adapted to a readiness probe that checked the wrong interface. Evidence: Source PR/commit evidence The author reproduced the local startup errors, then reported four consecutive orchestrator passes and three gateway passes after the fix. ([Source](https://github.com/uber/submitqueue/pull/64)) Use it when: Containers report healthy before the network interface used by the tests accepts connections. Before applying it: Probe the same protocol, authentication and readiness condition the consumer uses, keep a bounded startup timeout with logs, and keep any retries until the new probe is proven. [Read more in the Uber playbook](https://starsling.dev/ci-playbooks/uber#protocol-readiness) [Primary source](https://github.com/uber/submitqueue/pull/64) ## CI optimization is continuous work. Apply this technique yourself, or use StarSling Runners for faster GitHub Actions and optional agent-driven optimization PRs, which teams on eligible paid plans can turn on. [Get self-improving CI](https://starsling.dev/products/runners) ## Related techniques ### [Complete the fixture before its timeout fires](https://starsling.dev/ci-playbooks/techniques/finish-fixtures-before-timeout) Exercise the event that advances the test, so it stops waiting on the timer that rescues it. 1 implementation · 1 company (Uber) ### [Shorten deliberate test waits](https://starsling.dev/ci-playbooks/techniques/shorten-proven-test-waits) Reduce waits whose timing requirements are known, preserving the timeout or consistency behavior the test is intended to cover. 2 implementations · 2 companies (Anthropic, Mastra) ### [Balance test work across shards](https://starsling.dev/ci-playbooks/techniques/balance-test-shards) Use measured runtimes or smaller test files to reduce the slowest shard, which determines when the suite finishes. 4 implementations · 4 companies (Linear, OpenAI, Ramp, Stripe) ## Company Playbooks ### [Anthropic](https://starsling.dev/ci-playbooks/anthropic) Run only affected tests ### [DoorDash](https://starsling.dev/ci-playbooks/doordash) Run build and test in parallel, sharded across CI agents ### [Linear](https://starsling.dev/ci-playbooks/linear) Benchmark the same job on faster hardware ### [Mastra](https://starsling.dev/ci-playbooks/mastra) StarSling runners for the slowest test workflow ### [OpenAI](https://starsling.dev/ci-playbooks/openai) Rank CI fixes by the minutes they save ### [Ramp](https://starsling.dev/ci-playbooks/ramp) Move a CPU-bound test suite to a faster CPU ### [Shopify](https://starsling.dev/ci-playbooks/shopify) Let an agent iterate against one CI metric ### [Spotify](https://starsling.dev/ci-playbooks/spotify) Build arm64 on native arm64 runners ### [Stripe](https://starsling.dev/ci-playbooks/stripe) Run only the tests a change can reach ### [Uber](https://starsling.dev/ci-playbooks/uber) Build the merge-queue speculations most likely to be needed ## Related guides Implementation guides for this technique. ### [Cut repeated test setup](https://starsling.dev/best-practices/github-actions/cut-repeated-test-setup) Move shared fixture work out of individual test cases and keep necessary cleanup. ### [Shard tests across parallel jobs](https://starsling.dev/best-practices/github-actions/shard-tests) Split a long suite with a matrix and your test framework’s sharding support. ### [Diagnose slow tests in CI](https://starsling.dev/github-actions/problems/slow-tests) Check common causes in order and confirm each with workflow evidence. ### [Optimize Playwright tests](https://starsling.dev/github-actions/optimizations/optimize-playwright) Choose trace and video retention and install the browsers your suite uses. ### [Make Vitest run mode explicit](https://starsling.dev/github-actions/optimizations/optimize-vitest) Pin run mode to the test command and bound the job with a timeout.