The Pause That Nothing Ends
A workflow can be built with a wait in the middle of it — do this, pause three days, then do that. The pause works. Everything before it runs, the run is marked as paused, and the message names the date it will continue. Nothing in the product ever comes back to it.
We found this auditing our own automation on 26 August 2026, and it is the most consequential thing this series has published about our own product. If you have built a workflow with a wait step in it, the actions after the wait are probably not happening.
This page explains exactly what does happen, because the behaviour is more specific than "it is broken" and the difference decides whether it has affected you.
What a wait step is for
It is the piece that turns a rule into a process. Without it, automation can only react: something happened, therefore do this, immediately. With it you can express the things businesses actually run on — send the invoice, wait seven days, if it is still unpaid send a reminder. Approve the requisition, wait until the goods arrive, then notify finance.
Every one of those is two actions and a gap, and the gap is the point.
What actually happens here
The workflow runs. Each action executes in order and is logged. It reaches the wait, works out that the time has not arrived or the condition is not yet met, and records a pause — with the record it was working on, the condition it is waiting for, and the date it should continue.
Then it stops. The run is marked as paused, and the log carries a line saying the workflow is paused until a named date and time.
That date arrives, and nothing happens. There is nothing in the product that looks for paused workflows. No scheduled task, no background job, no periodic sweep. The pause is recorded faithfully and it is recorded for nobody.
The message is not wrong about the intention. It is a promise made by the part of the system that had no way of knowing nobody was going to keep it.
Whether it has affected you depends on one thing
And this is the part worth reading carefully, because the outcome differs sharply depending on what starts your workflow.
A paused run is never resumed — that is true in every case. But a workflow can be triggered again, and a fresh trigger starts a new run from the beginning. By the time that happens the wait may be satisfied, in which case the new run goes straight through it and carries on to the actions beyond.
Your workflow starts on a one-off event
The later actions never run
A record being created happens once. There is no second trigger, so there is no second run, and everything after the wait is simply never reached. This is the serious case.
Your workflow starts on a repeating event
They may run, and the earlier ones repeat
A record being updated can happen many times. A later update starts a fresh run which may pass the wait — but it re-executes every action before the wait too. So the tail of the workflow eventually fires, and the head of it fires repeatedly.
The second case is the one that produces the odd symptoms people notice without diagnosing: a notification that arrives several times, or a status that gets set again and again, while the step everybody was waiting for arrives late or erratically.
How to tell whether this is you, in five minutes
-
List your workflows and find the ones with a wait or delay step
If none of them has one, none of this applies to you and the rest of your automation is unaffected. This is the whole of the exposure.
-
Open the run history for one of them
Look for runs sitting in a paused state. A run paused past its stated date is a run that has stopped, not one that is still counting down.
-
Check whether the actions after the wait ever happened
Take a specific record from a paused run and check the thing that should have followed — the reminder, the notification, the status change. This is the only step that gives you a certain answer.
-
Rebuild the tail as its own rule for now
The workaround below. It gets the outcome without the pause, and it works today.
The workaround, which is better than it sounds
Split the workflow at the wait, and make the second half its own rule triggered by something real rather than by elapsed time.
The invoice reminder is the clearest example. Instead of send invoice, wait seven days, send reminder, use the scheduled reminders that already exist and run daily — they look at invoices, work out which ones are overdue, and send. That is a working, tested path, it has been running for a long time, and it does not depend on a pause resuming.
The general form: where you were waiting for time, look for a scheduled task that already asks the question daily. Where you were waiting for a condition, trigger the second half on the event that satisfies the condition instead. A workflow that fires when the goods are received is more reliable than one that pauses until the goods are received, and it is more honest about what it is doing.
What we are doing
The resume is being built rather than the step being removed, because the recording half is correct and complete — the pause knows the record, the condition and the time it is due. What it needs is something to come and look. It is recorded as a priority item in our internal register, and this page exists so that anybody relying on a wait step today knows before they find out from a reminder that never arrived.
Three, and the first is the whole of the fix
The pause already stores everything a resume would need. What has to exist is the thing that reads it.
A sweep that resumes paused runs
A scheduled task that finds pauses whose time has arrived or whose condition is now met, and continues the run from the step after the wait — without re-running the steps before it.
Paused runs visible and countable
A view of what is currently paused, for how long, and past its due date — so a pause that outlives its schedule is a number somebody sees rather than a row nobody queries.
A maximum wait, and what happens at the end of it
A pause that has waited beyond a limit should do something — abandon with a reason, or escalate. A wait with no upper bound is how an automation goes quiet without failing.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If you have a wait step in a live workflow, contact us and we will help you work out what it has and has not done.
Talk to us about your workflowsWhat AWRA OpsHub does today
- Event-triggered workflows across the modules, with conditions, and every action logged with its outcome, its duration and the record it ran against.
- A run history per workflow, so what fired, when, against what, and with what result is answerable after the fact.
- Scheduled reminder tasks that run daily — overdue invoices, approval inboxes, task due dates, stock and expiry alerts — which are independent of workflow pauses and are the reliable route for anything time-based.
- A failure digest, so a workflow whose integration step is failing reports itself rather than going quiet.
- A wait step that records the record, the condition and the due time when a run pauses, which is the half a resume needs.
More we can add to your workspace
- A sweep that resumes a paused run when its time arrives or its condition is met, continuing from the step after the wait.
- A view of currently paused runs, with how long each has been waiting and which are past due.
- A maximum wait with a defined outcome, so a pause that outlives its schedule escalates or abandons with a reason.
- Resumption from the step after the wait, rather than a fresh trigger re-running the whole workflow from the beginning.
Where we point you to a specialist
- We would rather publish this on the day we found it than wait until the fix ships. A customer relying on a wait step needs to know now, and a vendor who only publishes the problems it has already solved is publishing marketing.
- The scheduled reminder tasks stay separate from workflow pauses and we would keep them that way. Time-based work that must not be missed belongs in something that runs every day regardless of what any individual run is doing.
- Where a control can be worked around rather than simply waiting to be built, we fix it before writing about it. This is a step that stops rather than a lock that opens, so publishing it costs a reader nothing and tells them something they can act on today.
The resume sweep, a paused-run view and a bounded wait are one piece of work we can scope and quote on.
The short version
If you have built an automation anywhere that says "do this, wait, then do that", go and check that the second half is happening. Not that the rule exists, not that it is enabled — that the action after the pause has actually occurred against a real record in the last month. A pause is the one part of an automation that fails without failing: it logs, it reports a date, it looks entirely healthy, and the only symptom is something that did not happen.
Check one workflow with a wait in it
Take a record that went through it, and look for the thing that should have followed the pause. If it is not there, split the rule in two and trigger the second half on an event instead — and talk to us, because we would like to help you find out what else it affected.
Talk to us about workflow automation