Probe Temporal Workflow State on a Schedule and Alert on Thresholds

Long-running Temporal workflows accumulate internal state, backlog sizes, retry counters, and processed totals, that nobody sees unless something asks. This blueprint asks on a schedule: io.kestra.plugin.temporal.workflow.Query invokes a registered query handler on a running workflow, an If task parses the JSON-encoded answer as a number, and Discord gets paged when the value crosses a threshold. Queries are read-only in Temporal, so the probe observes state without ever mutating it.

How it works

1. probe_state (io.kestra.plugin.temporal.workflow.Query) calls the query handler named by query_type, getBacklogSize by default, on the latest open run of workflow_id. The task exposes one documented output, result, which carries the handler's return value as a JSON-encoded string.
2. check_state (io.kestra.plugin.core.flow.If) parses that string with Pebble's number filter and compares it against backlog_threshold. This works because the alert condition rides on the documented result output with a handler that returns a plain number; a handler returning an object would need a jq extraction first.
3. On breach, page_discord posts the workflow ID, the query type, and the reported value. Otherwise log_healthy writes a log line, so the execution history becomes an hourly state timeline.
4. The errors block pages Discord separately when the probe itself fails, which usually means the workflow is not running or the query handler is not registered, both worth knowing immediately.
5. A disabled-by-default Schedule trigger runs the probe hourly.

What you get

• Visibility into workflow-internal state without adding any alerting code to the Temporal worker.
• A read-only probe, guaranteed by Temporal's query semantics.
• A threshold alert with the exact reported value, not just a binary up or down.
• A distinction between a workflow reporting a problem and a workflow that cannot be reached at all.

Who it's for

• Teams running entity workflows or long-lived processors on Temporal that carry health-relevant counters.
• On-call engineers who want backlog growth paged before it breaches an SLA.
• Platform teams adding monitoring around workers they do not own.

Why orchestrate this with Kestra

The workflow already knows its own state; what is missing is something outside it that asks regularly, applies a threshold, and escalates. Baking that into the worker couples alerting policy to business code. Kestra keeps the policy outside: the schedule, the threshold, and the paging channel are flow-level configuration, changeable in a YAML review without redeploying a single worker.

Prerequisites

• A running Temporal workflow whose implementation registers a query handler matching query_type and returns a numeric value.
• A Discord incoming webhook for pages 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. Point workflow_id and query_type at a running workflow with a numeric query handler.
3. Execute the flow once manually, check the log line or the Discord page, then set disabled: false on the hourly trigger.

How to extend

• For handlers returning objects, extract a field with Pebble's jq filter before the comparison.
• Probe several workflows by wrapping the query in a Loop over a workflow ID list.
• React to a breach with more than a page: send a corrective signal, as shown in the Temporal signal broadcast blueprint.
• Put a hard completion SLA on the same workflow, as shown in the Temporal stuck workflow guard blueprint.

Links

• Temporal plugin documentation
• Temporal queries documentation