The simplest polling loop runs check() and either returns its truthy result or sleeps for intervalMs and tries again. await keeps the loop linear and exception-safe: an error in check rejects the outer promise instead of silently retrying. Use this for fast, synchronous-feeling waits where the worst case (hung loop) is acceptable. The major footgun is no upper bound: if the condition never becomes true, the loop runs forever, which is why production code uses the timeout variant.

Comparing Date.now() - start against timeoutMs caps the total wait, regardless of how long any single check takes. Throwing an error on timeout lets the caller decide whether to retry, surface the failure to the user, or fall through to a slow path. Keep the timeout proportional to the upstream's worst-case latency: too tight and you alarm on healthy systems; too loose and a real outage takes minutes to surface. Pair this with structured logging that records start, attempt, and the final outcome.

Doubling the delay on every miss spreads load away from the upstream during slow recovery windows, and the random jitter staggers clients that all started polling at the same wall-clock instant (a deploy, a cron tick). Capping delay at maxMs keeps the worst-case wait bounded so a flaky check does not stretch into multi-second pauses. The total wall-clock time becomes a sum of geometric delays, so adjust timeoutMs accordingly. This shape is the default for SDK polling loops (AWS, Kubernetes, GitHub Actions) and is what you should reach for whenever the consumer is shared infrastructure.