> For the complete documentation index, see [llms.txt](https://docs.drizz.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.drizz.dev/writing-tests/waits-and-timing.md). # Waits & timing Drizz supports **fixed-duration waits**. A wait states how long to pause, not what to wait for. | | | | -------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Platforms** | Android · iOS | | **What's supported** | Fixed durations only | | **Spellings** | `Wait Until 3 Seconds` · `Wait for 5 seconds` · `Wait until 10s` · `Wait 5s` | | **Cost** | Wait steps are not billed | | **Watch out** | Element-conditioned wording (`Wait until "Cart"`) is accepted by the editor but has no confirmed polling behavior | ## Prerequisites * A connected device or emulator * An open test file ## Copy this ``` OPEN_APP com.shopease.android Wait Until 5 Seconds Tap on Log in Type 9000000000 in the mobile number field Tap on Continue Wait Until 3 Seconds Type 123456 in the OTP field Tap on Verify Wait Until 5 Seconds Validate that the home screen is visible ``` ## Size a wait 1. Run the test and note the slowest time the screen took to appear. 2. Write `Wait Until Seconds` with that duration, rounded up. 3. Put the wait directly after the step that triggers the navigation or network call, before the step that needs the new screen. 4. Add a `Validate` on the next line. Validations get up to 3 attempts, which absorbs jitter on top of the wait. 5. Re-run the test and confirm the validation passes on its first attempt. ``` Tap on Place Order Wait Until 5 Seconds Validate that Order Placed is visible ``` ## The four spellings All four are the same command: | Spelling | Notes | | ---------------------- | ----------------------------------------- | | `Wait Until 3 Seconds` | The form the editor's `/` palette inserts | | `Wait for 5 seconds` | - | | `Wait until 10s` | - | | `Wait 5s` | - | Note: Use one spelling across a suite. ## Where waits go | Position | Duration | | --------------------------------------------------------------- | ------------------------------------- | | After any tap that navigates or triggers a network call | Sized to the slowest observed run | | After login, before the first validation on the landing screen | Sized to the slowest observed run | | After a payment or a submission, before validating the result | Sized to the slowest observed run | | After `OPEN_APP` | 3 to 5 seconds. More for a cold start | | Before a `Type` into a field that renders after the screen does | Sized to the field's render time | {% hint style="success" %} Waits are not billed. A wait costs wall-clock time in the run and nothing else. {% endhint %} ## Retries are not waits | | What it does | What it doesn't do | | ---------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------- | | **A wait** | Pauses for a fixed duration | Nothing else — it doesn't check the screen | | **Validation retries** | Re-checks the assertion up to 3 times in case of transition state of app | Doesn't help a `Tap`, `Type` or `Scroll` land on the right screen | Validation retries cover a screen that arrives a moment late. They do not cover a screen that takes four seconds — the three attempts are exhausted before the screen is ready, and the step fails. ## Common mistakes
What you wroteWhat happens
Wait until "Proceed to Pay" is visibleThe line is accepted, but there's no confirmed polling behind it. Use a fixed wait, then validate
Wait until the dashboard loadsSame. Replace with Wait Until 5 Seconds
No wait after OPEN_APPThe first tap fires at the splash screen and resolves to nothing
No wait between a tap that navigates and the validation after itThe validation runs against the previous screen, burns all 3 attempts and fails
Wait Until 30 Seconds sprinkled through a suiteA 40-step test now takes ten minutes longer, and the real timing bug is still there
A wait longer than 10 secondsThe step before it did not complete, or the screen itself needs raising with the app team
Removing a wait because "the validation retries will handle it"Retries cover jitter, not latency
Waiting after the validation instead of before itThe validation has already failed. Waits go before the step that needs the screen
## Next * [Validate](/writing-tests/tap/validate.md) — retries, and what to assert once the screen arrives * [The shape of a test](/writing-tests/writing-tests.md) — where waits sit in the five beats * [Command index](/writing-tests/command-index.md) — every command in one table *** *Last updated: 6 August 2026*