# Pause Until

Pause Until blocks a contact until a condition is met or until a timeout is reached.

<figure><img src="/files/wj4qoWRx1EZ4sDgDaCBl" alt="Pause Until step panel showing a condition source selector, event table configuration, timeout duration, and two outgoing paths"><figcaption><p>The Pause Until step panel — configure a condition source, set a timeout, and connect both the condition met path and the timeout path.</p></figcaption></figure>

## What Pause Until does

When a contact reaches a Pause Until step, DinMo monitors the condition you configured. As soon as the condition becomes true, the contact moves forward through the **condition met** path.

If the condition never becomes true before the maximum duration is reached, the contact moves forward through the **timeout** path instead.

Pause Until always creates **two outgoing paths**:

| Path              | When it triggers                                             |
| ----------------- | ------------------------------------------------------------ |
| **Condition met** | The configured condition became true before the timeout      |
| **Timeout**       | The maximum duration elapsed without the condition being met |

This makes Pause Until useful for event-driven sequencing where you want to react to something real — but also want a fallback if it never happens.

{% hint style="info" %}
If you just need a fixed time delay with no condition logic, use [Wait](/journey/concepts/wait.md) instead. Pause Until adds complexity that is only justified when progression depends on a real condition.
{% endhint %}

## Common use cases

| Condition                        | Timeout | Typical use                                                  |
| -------------------------------- | ------- | ------------------------------------------------------------ |
| Purchase event occurred          | 7 days  | Continue after purchase; send a reminder on timeout          |
| Profile field `activated = true` | 14 days | Continue once onboarding completes; escalate on timeout      |
| Email open event occurred        | 3 days  | Send follow-up only if they opened; re-route if they did not |
| Trial converted event            | 30 days | Continue to paid-user flow; re-engage on timeout             |

## Condition sources

### Profile fields

Use profile-field conditions when the Journey should continue once a customer attribute changes.

**Example:** continue when `onboarding_complete = true` or when `plan_status` changes from `trial` to `active`.

DinMo evaluates the condition against the contact's current profile during each Journey run.

### Event table

Use event-based conditions when the Journey should continue after a tracked event happens.

**Configuration:**

| Field            | Description                           |
| ---------------- | ------------------------------------- |
| Event table      | The event model to monitor            |
| Event conditions | Optional — filter by event properties |

## Timeout behavior

The timeout defines the maximum duration a contact will wait at this step before falling through to the timeout path.

{% hint style="warning" %}
If no timeout is set, contacts may wait at this step indefinitely. Always set a timeout unless indefinite waiting is truly acceptable for your use case. The publish checklist will warn you if Pause Until has no timeout.
{% endhint %}

| Timeout constraint | Value                                         |
| ------------------ | --------------------------------------------- |
| Minimum            | Greater than 0                                |
| Maximum            | 365 days                                      |
| Default            | No timeout (indefinite) unless explicitly set |

## Connecting the two paths

Both paths must be connected to continue the Journey. A common mistake is connecting only the **condition met** path and leaving the **timeout** path unconnected.

For the timeout path, common choices are:

* A different Activate step (for example, a fallback communication)
* A Stop step (if no further action is needed)
* A different Segment or Wait step (if the flow should continue differently)

## When Pause Until is the right choice

Choose Pause Until when:

* Progression should depend on a real event or a profile change, not just elapsed time
* You want to react immediately when the condition is met, rather than waiting a fixed duration
* You need a timeout fallback so contacts do not wait forever

Choose [Wait](/journey/concepts/wait.md) instead when:

* The next step should simply happen after a fixed duration
* There is no condition that would trigger earlier continuation

## Best practices

* Always set a timeout.
* Connect both the condition met path and the timeout path.
* Keep the timeout business-appropriate — a 365-day wait is almost never the right choice.
* Use Pause Until when the condition is meaningful. Do not use it as a workaround for a simple delay.

## Related pages

* [Wait](/journey/concepts/wait.md)
* [Choosing Wait vs Pause Until](/journey/best-practices/choosing-wait-vs-pause-until.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.dinmo.io/journey/concepts/pause-until.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.