Concurrency modes

What concurrency controls

Concurrency is evaluated when a signal tries to start an automation that already has related work in progress. It determines whether the new run waits, starts in parallel, replaces earlier work, is delayed until input settles, or is suppressed during a cooldown.

Queue

Queue runs every accepted event in arrival order. Use it for paid donation reactions, Channel Point reward videos, TTS requests, or file updates where each event matters. Set a maximum queue length and choose Drop Oldest or Drop Newest deliberately; dropping an event does not automatically refund or reverse the external service action.

Parallel

Parallel starts several runs together up to Max Parallel Per Automation. Use it for independent API lookups or messages that do not modify the same variable, file, OBS source, or scene. Avoid it when runs share mutable state because completion order is not guaranteed.

Cancel Previous

Cancel Previous stops the active related run and starts the newest request. Use it for a now-playing card, preview panel, search result, or temporary overlay where only the latest state matters. Cleanup actions in the cancelled run may not execute, so design the replacement run to establish the complete required state.

Debounce

Debounce waits for a quiet interval and retains the latest request. Use it for rapid slider changes, repeated text edits, resize events, or a burst of updates where only the final value should be applied. It is not suitable when every viewer purchase or donation must be processed.

Cooldown

Cooldown accepts a run and suppresses related calls during the configured interval. Use it for chat commands, sound effects, scene jokes, or expensive API calls that should not be spammed. A per-user cooldown lets different viewers use the feature independently while limiting repeated calls from one viewer.

Key Selector

A Key Selector divides one automation's coordination into independent lanes. Use {event.user.id} for a separate queue or cooldown per viewer, a reward ID for each reward type, or a destination identifier for each controlled resource. An empty, missing, or unstable key can group unrelated events or create unexpected lanes, so test the resolved value in Runtime.

Individual step behavior

A normal step does not own an independent concurrency queue. The automation run remains active while Source Show, Pause, a macro, an AI call, or another long-running step executes, and the automation's concurrency mode controls new signal calls during that time. Step Condition decides whether that step runs; Timeout and On Error control its failure behavior. They do not replace automation concurrency.

Real example: one reward

A Channel Point reward calls a macro that shows an OBS video, pauses for six seconds, and hides it. Queue ensures repeated redemptions of that same automation play one after another. Cooldown is preferable when duplicate reactions may be skipped instead of guaranteed.

Folder concurrency

Folder concurrency creates one coordination boundary for several automations. Put Reward 1, Reward 2, and Reward 3 in a Twitch Rewards folder and select Queue so different videos cannot overlap even though they originate from different signals. The folder mode coordinates entry into the group; each automation can still have its own cooldown or key behavior.

Real example: shared OBS overlay

Donation, raid, prediction, and reward automations may all use the same overlay area. Place only the reactions that must be mutually exclusive in one queued folder. Keep unrelated chat logging or counters outside it so a six-second animation does not delay background work.

Choosing a mode

• Every event must run: Queue.
• Only the newest state matters: Cancel Previous.
• Only the final value after a burst matters: Debounce.
• Spam must be restricted: Cooldown.
• Runs are independent and safe together: Parallel.
• Several automations share one OBS or audio resource: Folder Queue.