"Send the follow-up two days after the offer", "wait for the payment system before reading the status", "do not fire everything in the same second" — timing questions appear in every second automation scenario in Bitrix24 (Alaio). The platform has several delay mechanisms, each built for a different scale, and most broken schedules come from using the wrong one. This guide sorts them: built-in delays for minutes and days, a robot for seconds, and a calculated-date pattern for "not now, but at the right moment".

What built-in delay options does Bitrix24 have?

Two. An automation rule can be set to execute after a delay — minutes, hours or days after the record enters the stage — which covers the classic "remind in 2 days if no reply" without any extra tooling. Inside the workflow designer, a pause activity holds the process until an interval passes or a specific date arrives, and the date can come from a field of the record. Both are reliable and free; their granularity is their limit — they think in minutes and days, not seconds, and they delay a whole step, not the gap between two robots inside one chain.

When do you need a pause of a few seconds?

When two consecutive steps race each other. A workflow updates a record and the very next robot reads it back before the update has settled; an external service confirms receipt but needs a moment before the result is queryable; two integrations write to the same card and collide. Short pause exists exactly for this: it waits the specified number of seconds — a value measured in seconds, not hours — then returns a success signal and the chain continues. Placed between "write" and "read back", it converts an intermittent, unreproducible failure into a boringly stable sequence.

How do I delay an action until a calculated date?

The built-in pause can wait until a date in a field — so the trick is computing that date. Nearest date by condition picks the closest date matching your rule and writes it to the record, and the pause activity or a delayed rule then fires exactly then. Difference between two dates covers the inverse: turn "how long since the last activity" into a number a condition can compare, so the process decides whether to wait at all. Date arithmetic patterns — formats, timezones, field types — are collected in the dates guide.

What are the pitfalls of long pauses?

Three, all learned the hard way. A running workflow keeps the logic it started with: editing the template does not change instances already sleeping in a pause, so a fix rolls out only as old instances finish — plan for the overlap. Long-sleeping instances accumulate: hundreds of processes paused for a month each hold their state and clutter monitoring, so prefer event-driven design — end the process and let a new rule fire on the next stage change — over one giant process that sleeps through the pipeline. And do not chain Short pause calls into minute-long waits: it is built for second-scale gaps between steps, while minute-and-above delays belong to the built-in mechanisms that survive restarts by design.

Where to go from here

Audit your current templates for the two smells: second-scale races patched with minute-long native delays (replace with a short pause) and month-long sleeping giants (split into stage-driven rules). The workflow guide covers structuring processes so timing stays visible, and the automation examples collection includes both delay patterns in context.