Sleep for a number of seconds
Stops the job for a fixed stretch of time and then carries on. Use it to give a remote system a moment to settle between two steps, or to space out calls to a service that rate-limits you.
The wait is unconditional. Nothing is polled and no status is checked, and the job holds its process for the whole duration. Nobody watching the job monitor can end it early. When you want a wait that a person can release, use Pause a Job instead.
Fields¶
Seconds¶
How long to wait. Leave it empty and the op waits 5 seconds.
Decimals work and are honoured down to the microsecond, so 0.25 and 3.5 are both real waits.
The field expands ${} placeholders, so the delay can come from the stash or from a global
variable.
Several values behave in ways the field label does not suggest:
| Value | What happens |
|---|---|
| empty | waits 5 seconds |
0 |
waits 5 seconds, because zero reads as "nothing was set" |
0.0 |
returns at once, because it is not literally zero |
30s |
waits 30 seconds, because the leading digits are taken and the rest dropped |
| text with no leading digits | returns at once |
| a negative number | the op fails and the step errors |
Text with no leading digits is the one to watch. A placeholder that never resolved is left in the
field as the literal text you typed, so ${my_delay} against a stash that has no my_delay counts
as zero, produces no wait and no warning. The log still reports what it was given, so the line reads
"sleeping for ${my_delay} seconds" and the next op starts immediately after it.
Logging and job behaviour¶
Two lines go to the job log, one before the wait and one after, both quoting the value the op is
working from. That is the value after placeholders expand and after the 5-second default has been
applied, so a blank field logs 5, not a blank. Neither line can be changed from the form.
The wait blocks the step. Cancelling the job from the monitor does not shorten it: the cancel request is only picked up when the next op starts, which is after the sleep has run its full length. The job keeps its process the whole time, and the job daemon counts that process as a running job, so a long sleep in a shared rule holds one of the concurrent job slots against everything queued behind it.
Timeout on the op's Options tab (see Rule Palette) does cut the wait short,
but not gracefully. A Timeout smaller than Seconds interrupts the sleep at the timeout and ends
the op with a rule timeout error, which fails the step. Use it as a safety net on a sleep driven
from the stash, not as a way to end the wait early.
The op writes nothing into the stash unless you fill in Return Key on the Options tab, in which
case that key is set to 1 after the wait.
This op runs again during a rollback pass by default, so a rule that sleeps on the way out sleeps a
second time on the way back. Clear Run Rollback on the op's Options tab when that matters.
Combining with other ops¶
Put it inside RETRY to space out attempts against a service that is slow to come up, or inside DO-WHILE condition with a check op to build a polling loop that gives up after a fixed number of rounds.
Pause a Job is the op for a wait with a human at the other end, and Request Approval for a wait that needs a decision recorded.
Examples¶
Let a restarted service finish coming up before the next check.
Seconds 30
Back off between polls, with the delay driven from the stash so a single variable tunes every wait in the rule.
Seconds ${poll_interval}