CloudFlow steps that call AWS APIs can now include “Waiters” – built-in polling mechanisms that block execution until a resource reaches a specified state (for example, an EC2 instance enters “running,” or a CloudFormation stack reaches “CREATE_COMPLETE” state). 

The flow does not advance until the waiter confirms the target condition, eliminating timing-related race conditions and “false-positive” successes.

Why this matters:

• Deterministic pipelines: By making each step state-aware, you remove arbitrary sleep statements and ad-hoc retries. That yields predictable, repeatable deployments and fewer flaky builds.
• Lower failure rates: Waiters leverage AWS service-specific back-off logic and error handling, so you avoid cascading errors caused by resources that are still provisioning.
• Tunable latency: The default poll interval is 15 seconds, but you can override MinDelay, MaxDelay, and MaxAttempts to balance pipeline speed against API call volume.
• Cost-efficient polling: Purpose-built waiters replace tight loops or aggressive custom polling, reducing superfluous API calls and the associated request charges.
• Optimized resource billing: Downstream tasks start only when prerequisites are truly ready, so you don’t keep compute, container, or runner capacity idle while waiting for eventual consistency.
• Predictable spend: More deterministic execution times make it easier to forecast run-time costs and spot anomalies.

To enable a waiter, add the waiter configuration block to any CloudFlow step that invokes an AWS API. 

To learn more about how to apply AWS Waiters, check out our Help documentation or raise a ticket with the DoiT support team.