Broadcast a Signal to Running Temporal Workflows

Signaling one Temporal workflow is a CLI one-liner; signaling fifty of them during an incident is a script someone writes in a hurry and loses afterwards. This blueprint turns that operational broadcast into a reviewable, repeatable flow: a Loop iterates over a list of running workflow IDs and io.kestra.plugin.temporal.workflow.Signal delivers the same named signal, such as pauseProcessing, resumeProcessing, or reloadConfig, to each one, with a reason string passed to every handler. Discord gets a summary with the exact delivery count.

How it works

1. The workflow_ids input takes a JSON list of running workflow IDs, and signal_name selects which registered signal handler to invoke on them.
2. broadcast (io.kestra.plugin.core.flow.Loop) iterates over the list; its direct child send_signal (io.kestra.plugin.temporal.workflow.Signal) targets {{ item.value }} and sends the signal with signal_reason as a single JSON-encoded argument. With no runId set, the signal reaches the latest open run of each workflow ID.
3. notify posts the signal name and the list length to Discord, so the channel records how many workflows the broadcast reached.
4. The errors block posts a distinct Discord alert when any delivery fails, since a partially applied pause is worse than no pause at all.

What you get

• One command that pauses, resumes, or reconfigures a whole fleet of running workflows.
• An execution history entry for every broadcast, with per-workflow task runs showing exactly which deliveries succeeded.
• A reason string attached to every signal, so workflow histories in Temporal record why they were signaled.
• A failure alert that flags partial application immediately.

Who it's for

• On-call engineers who need to pause a class of workflows while a downstream dependency is degraded.
• Platform teams rolling out configuration changes to long-running workflows without restarting them.
• Anyone replacing ad hoc temporal CLI loops with an auditable operational runbook.

Why orchestrate this with Kestra

Temporal handles the signal semantics inside each workflow, but the broadcast itself, which IDs to hit, in what namespace, with what argument, and who gets told about it, is operational plumbing. Kestra keeps that plumbing declarative: the ID list and signal name are typed inputs, the endpoint lives in a secret, every run is auditable, and the same flow serves the incident at 3 a.m. and the planned maintenance window.

Prerequisites

• Running Temporal workflows whose implementations register a signal handler matching signal_name.
• A Discord incoming webhook for the summary and failure alerts.
• For Temporal Cloud, set the task's apiKey property; for mTLS clusters, provide caCert, clientCert, and clientKey.

Secrets

• TEMPORAL_ENDPOINT: Temporal frontend address in host:port format, for example temporal.example.com:7233.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the two secrets to your Kestra namespace.
2. Execute the flow with the IDs of a few running workflows and a signal name their implementation registers.
3. Check the Discord summary and confirm the signals in each workflow's history in the Temporal UI.

How to extend

• Build the workflow ID list dynamically from an upstream task, such as a database query or an API call, instead of a static input.
• Add a second Loop that queries each workflow after signaling to confirm the state change, as shown in the Temporal workflow state probe blueprint.
• Pair the pause broadcast with a resume broadcast in a second flow and chain them around a maintenance task.
• Start workflows in bulk rather than signaling them, as shown in the Temporal batch launcher blueprint.

Links

• Temporal plugin documentation
• Temporal signals documentation