Script icon
If icon
SlackIncomingWebhook icon
Log icon
Schedule icon
Webhook icon

Kestra Cluster Execution Backlog and Worker Starvation Watchdog

Automated SRE watchdog for Kestra clusters. Monitors execution queue latency, detects worker starvation, and flags zombie executions.

Categories
BusinessCoreInfrastructure

In distributed Kestra cluster deployments handling high-frequency production workloads, maintaining queue health and worker pool responsiveness is critical for operational stability. When worker instances experience memory exhaustion, thread pool deadlocks, or network partition events, incoming task runs can silently pool in QUEUED state, creating a growing execution backlog that compromises downstream service level objectives (SLOs). Similarly, un-isolated third-party scripts without explicit task timeouts can become zombie processes, holding concurrency slots indefinitely.

This blueprint implements an autonomous SRE reliability watchdog for Kestra clusters. It regularly samples cluster execution telemetry, measures queue latency against pre-configured thresholds, isolates hung tasks, detects runaway executions exceeding duration ceilings, and dispatches an incident card to SRE on-call.

How it works

  1. collect_cluster_metrics (io.kestra.plugin.scripts.python.Script) queries Kestra's internal execution state APIs (or prepares simulated telemetry during demo mode) to evaluate active execution distributions, calculate p95 wait times, and isolate executions lingering past max_queued_seconds_threshold.
  2. evaluate_cluster_health_gate (io.kestra.plugin.core.flow.If) evaluates the calculated health verdict. If worker starvation or zombie processes are detected, it dispatches an incident alert card to Slack and emits an itemized audit log; otherwise, it logs nominal operating bounds.

What you get

  • Proactive detection of worker thread pool exhaustion before systemic cluster backlog occurs.
  • Automated isolation of runaway zombie executions holding valuable concurrency slots.
  • Zero-setup demo execution via the seed_demo_data toggle with pre-configured queue starvation samples.
  • Declarative cluster self-monitoring that avoids external metric polling agents.

Who it's for

  • Site Reliability Engineers (SREs) maintaining enterprise Kestra cluster infrastructure.
  • Platform Engineering teams managing Kubernetes worker auto-scaling and resource quotas.
  • Cloud Operations leads responsible for orchestration availability and execution SLOs.

Why orchestrate this with Kestra

Using Kestra to monitor Kestra's own worker pools creates a self-healing operational loop. Declarative orchestration allows platform teams to embed queue diagnostics, timeout alarms, and Slack escalations directly within native flows without maintaining bespoke monitoring daemons.

Pitfalls

  • Queue spikes during scheduled bursts: High-concurrency cron schedules (e.g. top of the hour) produce expected transient queue spikes; calibrate max_queued_seconds_threshold to prevent alert noise.
  • Intentionally long-running workflows: Long-running ML training or streaming tasks must set task-level timeout: properties to distinguish expected long executions from stalled zombies.
  • Internal API network routing: Ensure the worker executing this watchdog can resolve the internal Kestra webserver service endpoint.

Prerequisites

  • Network connectivity from Kestra workers to the Kestra API endpoint.
  • Slack incoming webhook endpoint for SRE alerts.

Secrets

  • SLACK_WEBHOOK_URL: Slack incoming webhook URL for dispatching cluster health alerts.
  • SRE_WEBHOOK_KEY: Secret authentication key for external observability webhook triggers.

Quick start

  1. Execute the flow with seed_demo_data: true to observe simulated worker starvation detection.
  2. Configure SLACK_WEBHOOK_URL in your Kestra namespace.
  3. Enable the 15-minute schedule trigger for continuous cluster queue oversight.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.