> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zeotap.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Wait for Condition
> Hold a user in a journey until a profile attribute updates or an event fires, within a maximum wait window. Users who qualify continue; users who do not are dropped when the window expires.
## Overview
The **Wait for Condition** node holds a user in a journey until a profile attribute updates or a specified event fires — within a maximum wait window that you configure.
It is a gate with a **single output**. Only users who meet the condition pass through to the next node. Users who do not qualify before the window expires are dropped from the journey, and remain visible in analytics.
### Wait for Condition compared with Delay
Both nodes pause a user mid-journey, but they solve different problems.
| | Delay node | Wait for Condition node |
| ------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Type** | Time-based | State-based |
| **Behaviour** | Pauses for a fixed duration. The user always continues once the timer ends — no condition is checked. | Holds the user until a condition on their profile is met. Users who do not qualify are dropped once the window expires. |
| **Use when** | You need a timed gap between messages and no state check. | You are suppressing sends to converters, waiting for a value to compute, or gating on state. |
See [Add a Delay](/articles/orchestrate-customer/add-a-delay) for the time-based node.
**Not the same as Add a Condition.** [Add a Condition](/articles/orchestrate-customer/add-a-condition) tests the condition at the moment the user arrives at the node and routes them straight away. Wait for Condition *waits* for the condition to become true, holding the user until it does or until the window expires.
### Key characteristics
| Characteristic | Detail |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| **Single output connector** | No second path is needed for users who do not qualify, so the canvas stays clean. |
| **Exponential backoff retries** | The condition is re-checked on a `10 × 2ⁿ` second interval — frequent at first, then progressively further apart. |
| **Default maximum wait of 1 Day** | Configurable from a dropdown. Users who do not qualify within the window are dropped. |
| **Passes through exactly once** | A user passes the first time the condition is met, regardless of any later fluctuation in the value. |
## Add the node to a journey
Navigate to **Orchestrate → Journeys** and open or create a journey. The journey must be in Draft or Edit mode.
Click the **+** connector below any node to open the **Choose an action** menu, then select **Wait for condition**. The tooltip confirms what the node does: *"Hold the user in the flow until a profile attribute updates or an event fires — within a max wait window."*
At the top of the configuration panel, the **Max Wait** section shows a dropdown set to **1 Day** by default. Select a different duration if your condition needs longer — or shorter — to resolve. Users who do not meet the condition within this window are dropped from the journey.
In the **Add a Condition** section, use the condition builder — the same one you know from audiences — to define when a user qualifies. Choose a condition type (attributes, events or IDs), set the operator and value, and add further conditions with AND/OR logic, nested blocks or NOT.
Click **Add Wait For Condition** to save. The chip on the canvas updates to summarise your condition. Connect the output connector to the next node — that path carries qualifying users only.
Users who do not meet the condition within the maximum wait window are dropped from the journey automatically. Their status is trackable in journey analytics, and you do not need to configure a second path or any downstream action for them.
### Example configurations
| Condition | What it waits for | Why you would use it |
| ------------------------------------------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------------------------------- |
| **Have Certain Attributes** — `Customer_Consent` **Equal** `yes` | Consent being recorded on the profile | Hold the user until consent is on file before sending a marketing message. |
| **Performed an event** — `checkout_complete` where `product_id` **Equal** `product_x` | A purchase of one specific product | Suppression: hold before a follow-up push until the user buys the promoted product. |
| **Have Certain Attributes** — `customer_tier` **Is not null** | A derived attribute finishing its computation | Wait until the value is ready before downstream personalisation reads it. |
Use **Add Nested Block** when you need grouped compound logic — for example, (A AND B) OR (C AND D). The outer AND/OR controls how the blocks relate to each other; the inner AND/OR controls the conditions within a block.
## How the node re-checks the condition
Each user's condition is re-evaluated on an **exponential backoff schedule**. The interval is `10 × 2ⁿ` seconds, where *n* is the retry number — 20, 40, 80, 160, 320 seconds and so on. Checks are frequent at the start, which suits conditions that resolve quickly, and space out as time passes.
| Retry (n) | Interval | Cumulative time elapsed |
| --------- | ----------------------------- | ----------------------- |
| 1 | 20 seconds | \~20 seconds |
| 2 | 40 seconds | \~60 seconds |
| 3 | 80 seconds | \~2 minutes |
| 4 | 160 seconds (\~3 minutes) | \~5 minutes |
| 5 | 320 seconds (\~5 minutes) | \~10 minutes |
| 6 | 640 seconds (\~11 minutes) | \~21 minutes |
| 7 | 1,280 seconds (\~21 minutes) | \~42 minutes |
| 8 | 2,560 seconds (\~43 minutes) | \~85 minutes |
| 9 | 5,120 seconds (\~85 minutes) | \~2.8 hours |
| 10 | 10,240 seconds (\~2.8 hours) | \~5.7 hours |
| 11 | 20,480 seconds (\~5.7 hours) | \~11.4 hours |
| 12 | 40,960 seconds (\~11.4 hours) | \~22.8 hours |
What this means in practice: a condition that resolves quickly — a derived attribute recomputing, for instance — is picked up within the first minute or so and the user moves on. A condition that takes hours, such as a purchase inside a 24-hour window, is checked at widening intervals rather than continuously for the whole wait. Twelve retries span roughly 22.8 hours, so a user sitting in the default 1-day window is checked about a dozen times before it expires.
### Passing through exactly once
Each user passes through the node exactly once. If the value fluctuates after the condition has been met — the attribute reverts and matches again, or the same event fires a second time — the user is not unblocked a second time. The first resolution is the trigger; later changes are ignored.
### When the maximum wait window expires
Users who have not qualified when the window expires are dropped from the journey. There is no second output path to configure on the canvas. Dropped users appear in journey analytics and stay fully trackable, and they do not hold up any other user in the journey.
## Track users at the node
Every user who enters a Wait for Condition node is tracked from entry to exit, with three statuses:
| Status | What it means |
| ------------------ | ------------------------------------------------------------------------------------------------------ |
| **Waiting** | The user is currently held at the node, with their condition being re-checked on the backoff schedule. |
| **Passed Through** | The condition was met within the window and the user has continued to the next node. |
| **Dropped** | The window expired without the condition being met. No downstream action is required. |
For per-node visibility across the whole journey, see [Understand Metrics](/articles/orchestrate-customer/understand-metrics).
### Reading your drop rate
| What you see | Likely cause | What to try |
| --------------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| High drop rate | The window is too short, or this audience rarely meets the condition. | Increase the maximum wait, or review the condition against your audience's profile data. |
| Most users qualify near the end of the window | The attribute or event is arriving slowly. | Check for latency upstream in your data pipeline, and consider widening the window slightly. |
| Very high pass-through rate | Most users already meet the condition when they arrive. | Consider moving the condition upstream, into the journey's entry criteria. |
| Zero pass-through | The condition is misconfigured, or the attribute or event is not being ingested. | Verify the attribute name, operator and value, then check that the event is being ingested. |
**Calibrating the window.** Run your first campaign with the default 1-day window and check analytics at the 24-hour mark. If most of your drops happened in the last couple of hours, a slightly longer window would have captured them. Two or three campaign cycles of this is usually enough to settle on the right duration.
## Use cases
### Suppressing a follow-up to users who converted
A user receives a promotional email for a product. Before the follow-up push goes out, you want to know whether they bought it — so that buyers are not pushed unnecessarily.
1. Add a Wait for Condition node between the **Send Email** node and the **Send Push Notification** node.
2. Set the condition to **Performed an event** — `checkout_complete` where `product_id` **Equal** `product_x`.
3. Leave **Max Wait** at the default of **1 Day**.
Users who purchase pass through, so no follow-up push is sent to them. Users who do not purchase within the day are dropped from the journey.
### Waiting for a derived attribute to finish computing
A CE attribute such as `lifetime_value` updates, and a downstream personalisation node reads the NCE attribute `customer_tier` derived from it. Recomputation takes time, and the personalisation node must not fire before the value is ready.
1. Add a Wait for Condition node between the update trigger and the node that reads `customer_tier`.
2. Set the condition to **Have Certain Attributes** — `customer_tier` **Is not null**.
3. Set **Max Wait** to a window that comfortably covers recomputation — for example, 2 hours.
Backoff retries begin immediately, checking after 20 seconds, then 40, then 80, so most recomputations are picked up within the first few retries. Users pass through as soon as the value is populated. Anyone whose attribute has not computed inside the window is dropped, which keeps stale data out of the personalisation node.
## FAQs
They are dropped from the journey. There is no second output path to configure. Dropped users appear in journey analytics and stay fully trackable, and they do not hold up any other user in the journey.
The node retries on exponential backoff — after 20 seconds, then 40, 80, 160, 320 and so on. Conditions that resolve in the first few minutes are typically caught within the first several retries. Conditions that take hours are checked at widening intervals.
AND requires every condition in the block to be true before the user qualifies. OR needs only one of them. Toggle between the two at the top-left of each condition block, and use nested blocks for compound logic.
NOT inverts the whole condition block: users who would not otherwise match are the ones who qualify. For example, NOT (`Customer_Consent` **Equal** `yes`) passes users through when consent is explicitly not `yes`.
No. A user passes through only the first time their condition is met, even if the value fluctuates afterwards. Later attribute changes and repeated event fires do not re-trigger the node.
Yes — both can be combined in sequence in the same journey. For example, a 30-minute Delay for a cool-down period, followed by a Wait for Condition node that checks for a purchase before the follow-up is sent.
So that fast-resolving conditions are caught within the first minute while slower ones are not checked every few seconds for hours on end. Backing off keeps the node responsive where it matters and predictable over long windows.
## Related Topics