Run After
Defers downstream execution by a specified number of seconds. Creates a fork of the current run that resumes after the delay.
Forks the run and resumes downstream nodes after a delay measured in seconds.
Inputs
- Key — String. Supplies the scheduler key that identifies the delayed run. Reusing the same key causes the executor to find and reactivate the existing delayed scheduler instead of creating a second one, which is how callers replace an outstanding delay or cancel the same scheduled fork later.
- Secondsrequired — Number. Supplies the delay length in seconds. The executor converts this value to an integer and schedules the fork to resume at the current UTC time plus that many seconds, so the value directly controls when downstream execution continues.
- Start Signal — Boolean. Starts the delay when true. If neither start_signal nor stop_signal is true, the node skips execution and returns an inactive signal.
- Stop Signal — Boolean. Cancels the delay when true. Stop takes priority, the scheduler is looked up by key, and both the scheduler record and its forked run are marked cancelled when they are still active.
Outputs
- Signal — Boolean. Represents that the delayed run has been scheduled and downstream execution is paused until the timer expires.
Configuration
- Scheduler Key — Text. Controls the default scheduler key used to find, reactivate, or cancel the delayed run. This matters because the key is the stable identifier for the scheduled fork, so changing it creates a different delay while keeping it the same lets the node coalesce repeated starts into one outstanding delay.
Example use cases
Delayed follow-up
Wait 86400 seconds after a ticket enters Waiting, then check whether it moved and nudge the assignee if not.
Debounce
Give the Scheduler Key a stable value so a fresh trigger replaces the pending timer instead of stacking duplicates.