Delay, Interval, Scheduler, Countdown, and Stopwatch are the workflow nodes that measure or wait for time instead of reacting to another node's value. Together they let a workflow start itself at a fixed time, hold a warning on screen while time runs out, stagger two actions so they don't collide, or simply track how long something has been running, without a person watching the clock. This recipe wires three of them into one realistic on-air changeover, and explains what each node remembers (and forgets) when a workflow reloads or Buttons restarts, since that's easy to get wrong by assumption.
For the field-by-field configuration of each node, see the workflow node reference; this page focuses on using them together predictably.
Familiarity with the values-vs-events model these nodes use: Delay, Countdown, and Stopwatch each expose both a state output (a number you can read at any time) and event outputs (things that fire once, at a moment).
Any Connection Actions the automation should trigger, already validated against their target device. This recipe treats them as a black box; see Troubleshoot a workflow if an action itself misbehaves.
Delay waits a fixed number of milliseconds before passing a value or event onward. It has two independent paths: connect Payload to delay a value, or connect Event to delay an event; each schedules its own timer.
Interval fires repeatedly on a fixed millisecond period, for as long as the workflow runs.
Scheduler fires according to a schedule you build with the node's Frequency (Daily, Weekly, Monthly, Yearly) picker, or by selecting specific months, days of the month, days of the week, hours, minutes, and seconds directly for a custom pattern, for example several weekdays at once. A plain-language summary confirms what you've built.
Countdown counts down from a duration you supply, and responds to Start, Pause, Reset, Restart (reset-then-start in one step), Set, Add Time, and Subtract Time events. Its Initial Duration is itself a connection: feed it a value (for example, from a Static Value node) rather than typing a number directly on the card. It reports Remaining (ms), Remaining (HH:MM:SS), Progress, Is Running, and Is Finished, and fires Started, Paused, and Finished events. The card's loop icon (tooltip Loop: on/Loop: off) makes it restart automatically instead of stopping at zero.
Stopwatch counts elapsed time upward from Start until Pause, Reset, or a Set event. Its Run on startup switch, right on the card, starts it automatically as soon as the node itself comes to life: useful for "how long has this been going" displays that shouldn't need a manual start.
Note
Right after you add a Countdown or Stopwatch node, its Start/Pause/Reset/Set buttons stay disabled with a tooltip asking you to apply the workflow first: the same "not initialized yet" state described in Troubleshoot a workflow. Select Apply once after adding one before trying its controls.
All five nodes keep their live timer or counter only in the memory of the running workflow: a countdown's remaining time, a stopwatch's elapsed time, an interval's or scheduler's running timer, and any value or event a Delay is still waiting to release all live in the process, not the database. Only each node's configuration (its Initial Duration connection, its interval, its schedule, whether Loop or Run on startup is checked) is saved. What that means in practice depends on what kind of reload happens:
What happens
Effect on these five nodes
You edit the workflow and select Apply, and the workflow stays enabled throughout
Nothing resets. A running Countdown or Stopwatch keeps counting from where it was; Interval and Scheduler keep firing on their existing timer; a Delay that's already waiting keeps waiting. Buttons only rebuilds a node's own timer when you change the field that defines it: Interval's interval, Scheduler's schedule, or Delay's own Delay (ms) value, and even then it's just that one node's timer restarting, not the workflow.
You disable a single node, or delete it, then bring it back
Full reset for that node. Buttons discards the running node and creates a brand-new one from its saved configuration next time the workflow runs: a Countdown or Stopwatch goes back to idle at its configured duration, an Interval or Scheduler's old timer is gone and a fresh one starts, and anything a Delay was holding is dropped.
You disable the whole workflow, then re-enable it
Same full reset, for every node in it.
Buttons itself restarts: an application update, a host reboot, or the workflow service being restarted
Same full reset, for every enabled workflow, because every workflow is rebuilt from its saved configuration when the service comes back up.
Node by node, a reset means:
Countdown goes back to its configured Initial Duration and sits idle: it does not remember that it used to be running and does not resume on its own. Something has to send it Start (or Restart) again.
Stopwatch goes back to 0 elapsed and sits idle, unless Run on startup is checked, in which case the fresh node starts itself from zero. That's the configured setting taking effect on a new node, not a resumed timer.
Interval starts ticking again from the moment the workflow's next render reaches it. It doesn't try to catch up to where it would have been if it had kept running.
Scheduler recalculates its next fire time from its configured schedule and the current time, rather than remembering "time until next fire." A schedule like "daily at 06:00" still fires at 06:00 after a reset, because that's what the schedule means, not because Buttons remembered a countdown to it. It only catches up a tick it detects it missed while its own timer was still running (for example, a brief overload); if Buttons wasn't running at all when a scheduled time passed, nothing was watching to notice the miss, and that occurrence is simply skipped.
Delay loses anything already waiting out its delay: a value or event queued for release does not survive, and nothing re-arms it after the fact. Once the workflow is running again, delays only start counting for whatever triggers them from that point on.
None of these five nodes has a setting to make their in-progress state survive a reset, unlike the Workflow Variable node's optional Persist Value, which is built specifically to bring a stored value back after a reload. A Countdown's remaining time or a Stopwatch's elapsed time isn't that kind of stored value; it's a running measurement that only exists while the node is alive.
Note
Countdown and Stopwatch each have their own Restart control, which means reset-then-start-again (a normal, on-demand action a person or another node triggers). Don't confuse that with Buttons itself restarting, which is the full reset described above.
A small radio station's control room runs an unattended handover from music to the news desk at a fixed time every weekday. The engineer wants on-air talent to see a visible 30-second warning before the changeover, and wants the two changeover actions (switching the source and unmuting the news mic) to land three seconds apart, so the mic doesn't come up on top of the tail of the music (an audible pop). The workflow already has validated Connection Actions for both steps.
Add a Scheduler node. In its Frequency picker, select each weekday (Monday through Friday) under Day of the week, then set Hours, Minutes, and Seconds to 08, 59, and 30. Confirm the plain-language summary reads back the schedule you intended.
Add a Countdown node. Add a Static Value node, set its type to string, and set its value to 00:00:30. Connect it to Countdown's Initial Duration input.
Connect Scheduler's Event output to Countdown's Start input.
Connect Countdown's Remaining (HH:MM:SS) output to a Display node (or your on-air graphic's source value), so the warning is visible while it counts down.
Connect Countdown's Finished event to the Connection Action that switches the source.
Add a Delay node set to 3000 ms. Connect Countdown's Finished event to Delay's Event input.
Connect Delay's Out event to the Connection Action that unmutes the news mic.
Select Apply.
Each weekday at 08:59:30, Countdown starts automatically, the on-air graphic counts down to zero, the source switches the instant it finishes, and the mic unmutes three seconds later. If Buttons happens to restart shortly after 08:59:30 but before the Countdown started (or while it's still idle from a previous day), nothing is lost; the Countdown simply waits for Scheduler's next weekday trigger. If it restarts while the Countdown is mid-run, though, that day's changeover doesn't complete on its own: the fresh Countdown comes back idle at 30 seconds and won't finish or fire its Connection Actions until Scheduler triggers it again the next scheduled weekday, so the engineer would need to run that day's changeover manually.
Check whether the workflow service restarted around 08:59:30 that day; Scheduler doesn't catch up a fire it missed while the whole process was down, and Countdown doesn't resume on its own after a restart.
The on-air countdown seems to have snapped back to 30 seconds unexpectedly.
The node (or the whole workflow) was disabled and re-enabled, or Buttons restarted: either fully resets Countdown to its configured Initial Duration.
Editing something else in the workflow reset a running Countdown or Stopwatch.
It shouldn't. Apply only rebuilds a node's own timer when that node's own timing field changes. Check whether the Countdown or Stopwatch itself was briefly disabled, or whether its Initial Duration input changed value.
The mic unmutes at the same instant the source switches, instead of three seconds later.
Confirm Delay's Event input is wired from Countdown's Finished event, and the mic's Connection Action is wired from Delay's Out, not both actions from the same Finished edge.
