SLA Guard for Long-Running Temporal Workflows

A Temporal workflow that never fails but also never finishes is invisible to most alerting: no error, no page, just a settlement that quietly did not happen. This blueprint puts a clock on it from the outside. io.kestra.plugin.temporal.workflow.Wait polls the workflow within a short waitTimeout, and because failOnNonCompleted is true, both an overrun and a FAILED, CANCELED, TERMINATED, or TIMED_OUT ending fail the Kestra execution, whose errors block pages Discord with the workflow ID and the breached window. The workflow itself needs no changes and can belong to another team entirely.

How it works

1. sla_wait (io.kestra.plugin.temporal.workflow.Wait) targets the latest run of workflow_id and polls every 30 seconds. The waitTimeout is the SLA: PT15M by default, set per run through the sla_window input.
2. When the workflow completes in time, the task returns its documented status and JSON-encoded result outputs, and log_within_sla records the compliant run.
3. When the window elapses first, or the workflow reaches a terminal state other than COMPLETED, failOnNonCompleted: true fails the task and execution jumps to the errors block.
4. page_sla_breach posts the workflow ID, the window, and the execution link to Discord, so on-call starts in the Temporal UI with context rather than from a vague timeout graph.

What you get

• An SLA on any Temporal workflow without touching its code or its worker.
• One page that covers both failure modes: taking too long and ending badly.
• A compliance log line for every run that met the window, giving you an audit trail of SLA adherence.
• A pattern that works against workflows owned by other teams, since it only needs the workflow ID.

Who it's for

• On-call engineers responsible for outcomes of workflows they do not implement.
• Platform teams attaching latency guarantees to critical business workflows like settlements or provisioning.
• Anyone who has been burned by a stuck workflow that raised no error for hours.

Why orchestrate this with Kestra

Temporal guarantees the workflow will eventually make progress or fail; it does not decide how long is too long for your business. That deadline is policy, and policy belongs outside the worker. Kestra holds it declaratively: the window is an input, the paging channel is a task, every guard run is in the execution history, and tightening the SLA is a one-line change nobody has to redeploy.

Prerequisites

• A running or recently started Temporal workflow to guard, identified by its workflow ID.
• A Discord incoming webhook for SLA pages.
• 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 against a running workflow with a window it will meet, and check the compliance log line.
3. Rerun with a deliberately short sla_window such as PT10S and confirm the Discord page arrives.

How to extend

• Start the guard right after starting the workflow itself, as shown in the Temporal launch-and-wait blueprint, to give every launch a built-in SLA.
• Guard a fleet by wrapping the wait in a Loop over workflow IDs.
• Escalate beyond a page: on breach, send a corrective signal to the workflow, as shown in the Temporal signal broadcast blueprint.
• Probe intermediate state before the deadline with the Temporal workflow state probe blueprint, catching slow runs before they breach.

Links

• Temporal plugin documentation
• Temporal documentation