Independent HighLevel affiliate publication. We may earn a commission if you buy through links on this page, at no extra cost to you.

Practical guide

A wait, a reply and a timeout mean different things

Last materially reviewed 2026-09-27

Quick answerChoose what ends the wait and what a timeout should do. Silence is not proof that a person is uninterested or that a message arrived.
What to know

State the waiting condition

A delay of a certain duration and a wait for a particular event solve different problems. The first controls timing; the second depends on an observable response. Write which condition is intended and what happens if it never occurs. Do not let the label “wait” conceal whether the workflow is listening for a reply, a field change or simply the passage of time.

What to know

Give timeout a modest meaning

When a timer ends, the strongest supported conclusion may be only that the expected event was not observed within that interval. The message could have failed, the recipient could be busy or the reply could have arrived through another channel. Choose an appropriate next step, such as a staff review, instead of assuming the person should receive an increasingly insistent series of messages.

What to know

Check the race with a human response

A staff member may answer while the automation is waiting. Decide whether that makes the queued action unnecessary. Review which documented event will represent the handoff and whether it affects this workflow instance. A separate task being completed or a note being added should not be assumed to stop a waiting message unless that behavior is explicitly implemented and verified.

What to know

Test the edge, not only the delay

Use synthetic cases where the response comes before the timeout, no response arrives, and a response appears near the boundary. Preserve expected versus observed outcomes, including any uncertainty about ordering. Do not manufacture a precise timing guarantee from one run. A simple, conservative branch is often easier to maintain than several overlapping timers that nobody can explain during an exception. Record the intended fallback when an event receipt is unavailable; that absence should not silently become a reason to send again.

Continue when useful

Next: Time windows: whose clock controls the message?

Record the timezone and the actions governed by the window. Changing an account clock is not proof that already-running entries were retimed.

Open Time windows: whose clock controls the message? →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Wait workflow action — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27
  2. Customer Replied trigger — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27