Wait

Pause the run for a set duration or until a time of day, optionally held to business hours or to a daily window so a customer is never messaged in the middle of the night.

Getting here

Automate → Workflows, open a workflow, click + on the canvas, then pick Wait under Add Steps.

Before you start

  • An owner, admin or agent can add this step and save the workflow. Publishing it is an owner or admin action.
  • Building and running workflows depends on your plan; see pricing.
  • Nothing outside Inchat has to be connected. Holding a wait to business hours needs them set in Settings → General.

Set up

  1. Open the workflow and click + where the pause belongs.
  2. Pick Wait.
  3. Choose Wait for a duration (seconds, minutes, hours or days) or Wait until a time of day.
  4. Optional: tick Only continue during business hours, or Only continue between set hours, every day — not both.
  5. Save the step, then publish the workflow.

Fields

Wait for a duration
A number and a unit — seconds, minutes, hours or days.
Limits: Seconds must be 15 or under, or 60 (one minute) or more — nothing in between. The overall cap is 90 days.
Wait until a time of day
A time of day. Resumes at the next occurrence of that time — tomorrow, if it has already passed today.
Limits: There is no time zone picker for this mode — it always resumes against Asia/Kuala_Lumpur time, whatever time zone the workspace or the contact is in.
Only continue during business hours
If the wait would end outside the workspace's business hours, it is held until the workspace next opens.
Default: off
Limits: Uses the hours set in Settings → General. Cannot be combined with the daily-hours hold below.
Only continue between set hours, every day
If the wait would end outside a fixed daily window (every day of the week, including weekends), it is held to the nearest moment still inside that window.
Default: off; 09:00–21:00 when switched on
Limits: The forward push applies whatever the wait's length. Pulling the held time back to stay inside the channel's messaging window only happens for a wait shorter than a full day — a wait that long or longer crosses the window by its own length regardless, which is treated as the author's own choice, not something to correct for. That backward pull is not specific to WhatsApp — it checks whichever channel's own messaging window applies. When no moment inside the window still fits, nothing is pulled back and the send can still land outside the window and fail when it fires. Cannot be combined with the business-hours hold above.

How it works

  • A short wait — 15 seconds or less, and only while the run's total of such short waits so far still fits in that same window — actually pauses the run in place; everything longer is scheduled and resumes when the drain next runs, not held open.
  • A scheduled wait is drained by a cron job that checks for due waits about once a minute — not the same job that drains incoming webhook events.
  • When a scheduled wait comes due, the workflow and the conversation are checked again before resuming: if the workspace has since lost access to workflows on its plan, the wait is quietly cancelled rather than resumed; if the workflow has been deleted, the resume is always refused; if it has been stopped, unpublished, or edited and republished, or the thread has since been taken over by a human, paused, or blocked, the resume is refused too — unless the wait sits after an answered Ask a Question, which is exempt from the stopped/unpublished/republished checks (not the deleted one); see Limits.
  • Only continue during business hours only ever pushes a due time forward, to whichever opening comes next. Only continue between set hours, every day also only pushes forward by itself — but if forward-holding it would carry the send past the channel's own messaging window, that hold is then pulled back to the latest moment still inside the window instead, which can land it earlier the same evening rather than the next morning.

When it fails

  • The workspace loses its workflows entitlement while a wait is pending: the queued continuation is silently cancelled — it does not run, and nothing about the original run is marked failed after the fact.
  • The workflow is stopped, unpublished, or edited and republished while a customer has a wait pending: that customer's queued continuation is dropped — it resumes against neither the old state nor the new one, unless the wait sits after an answered Ask a Question in the same flow; see Limits. The workflow being deleted is never exempt, even then.
  • The thread has been taken over by a human, paused, or the contact blocked, by the time a scheduled wait comes due: the resume is refused, unless every remaining step is one that only writes internally (a tag, a field, a note) rather than reaching the customer — that kind of continuation still runs even on a held thread.
  • You read the reason in the workflow's Activity tab: pick the run under Execution log and the step's line names it.

Limits

  • It cannot pause for longer than 90 days in one step.
  • A wait of a day or more usually outlasts the 24-hour window on WhatsApp, so whatever comes after a long wait on that channel should be a template, not a plain message.
  • Stopping, unpublishing, or editing and republishing a workflow drops every customer's wait queued against it, EXCEPT one that sits after an answered Ask a Question in the same flow: that continuation is bound to the copy of the workflow the customer was shown when asked, so it keeps resuming against that same, now-superseded copy even after the workflow is stopped or republished. Deleting the workflow is not exempt even then.
  • The two hold options are mutually exclusive; the save boundary refuses a workflow with both set on the same wait.

Best practices

  • For a follow-up aimed at a customer, hold it to set hours rather than business hours — set hours apply every day including weekends, so a Saturday-night wait still resumes on Sunday morning instead of waiting until Monday.
  • Reserve business-hours holding for a wait whose next step needs the team, not the customer — a hand-off or a call-back promise.
  • Avoid republishing a workflow that has a long wait actively pending on it if the queued follow-up matters — publish the change once those waits have cleared instead.

Use cases

  • A payment reminder waits a day, checks whether the invoice is still open, and only then sends the next nudge.
  • A quote sent late at night waits two hours before following up, held to set hours so the follow-up lands the next morning rather than after midnight.

FAQ and troubleshooting

Can Wait hold until a specific date, like 'March 5th at 6pm'?
Not directly — Wait holds for a duration or until a time of day. For a fixed date, use Date & Time (business hours) with a date range, or trigger the workflow from a date-based trigger.
I republished (or stopped) my workflow and a customer's follow-up never arrived.
A wait queued against a workflow is dropped when that workflow is stopped, unpublished, or edited and republished — it does not resume against the old state or the new one. The one exception is a wait that sits after an answered Ask a Question: that continuation is bound to the copy the customer was shown, so it keeps resuming against it even then. Deleting the workflow drops the wait regardless. Publish changes once pending waits have cleared, or accept that other in-flight ones will not fire.

Related

  • Date & Time (business hours) — Route the run down an Open or a Closed path depending on business hours or a date range, checked the instant the step runs, with no branch treated as a dead end.
  • Remove from Workflow — Cancel this conversation's pending waits — the step that stops a reminder chase the moment the contact replies or pays, before the next one is due.
  • Avoid workflow loops — What already stops a flow from re-triggering itself, and the two hard caps — on Jump To and on Trigger Another Workflow — that stop a deliberate loop from running forever.

Reading this with an AI assistant? Plain Markdown version.