GetJob icon
Return icon
Switch icon
Log icon
SlackIncomingWebhook icon
Schedule icon

Stream Analytics Job Health Gate

Audit Azure Stream Analytics job state and alert Slack when a streaming job fails, degrades, or stops unexpectedly.

Categories
CloudInfrastructure

A Stream Analytics job that stops, fails, or degrades does not page anyone on its own, the input stream keeps arriving and queuing up while the job sits there, and the first sign of trouble is usually a downstream dashboard that silently stopped updating. GetJob already reports the real jobState (Running, Degraded, Failed, Stopped, and more) and provisioningState, this blueprint is what reads that on a schedule and turns an unexpected state into an alert before anyone notices missing data.

How it works

  1. probe_job_status (io.kestra.plugin.azure.streamanalytics.GetJob) reads the job's real jobState and provisioningState, with allowFailure: true so a bad credential or a renamed job does not stop the flow before it can be classified as PROBE_FAILED below.
  2. classify_job_health (io.kestra.plugin.core.debug.Return) returns PROBE_FAILED when probe_job_status produced no output at all, CRITICAL on jobState: Failed or a Failed/Canceled provisioningState, CRITICAL or WARNING on jobState: Degraded depending on degraded_is_critical, HEALTHY when jobState matches expected_job_state and provisioningState is Succeeded, and WARNING for every other combination, for example a job still Starting or Scaling.
  3. route_by_job_health (io.kestra.plugin.core.flow.Switch) branches on that status: HEALTHY logs both real states, WARNING, CRITICAL, and PROBE_FAILED each alert Slack with those same real states, never an invented one.
  4. log_audit_summary always runs last and logs the final classification.
  5. The errors block posts to Slack if the flow itself fails outside the gate logic above.

What you get

  • A real answer to whether a streaming job is actually Running, not an assumption that it still is because nobody has looked recently.
  • A Slack alert carrying the job's own jobState and provisioningState, never an invented explanation of what went wrong.
  • A policy choice for jobs that are intentionally Stopped between batch windows (expected_job_state) and for jobs with a known tolerance for brief degradation (degraded_is_critical), instead of one fixed definition of healthy for every job.

Who it's for

  • Data platform and streaming teams running Azure Stream Analytics jobs who need to know about a stopped, failed, or degraded job before a downstream dashboard or alerting pipeline goes quiet.
  • Teams evaluating the Stream Analytics plugin who want a working example of streamanalytics.GetJob and the real jobState/provisioningState values it returns.

Why orchestrate this with Kestra

GetJob is a single point-in-time read, Stream Analytics itself has no concept of a schedule, an expected state per job, or an alert built from what it finds. Kestra adds the recurring check, the per-job expected-state policy, and a Slack alert built only from the job's own reported states, all as one declarative YAML file you can version and review like code.

Prerequisites

  • An Azure Stream Analytics job and a service principal with Microsoft.StreamAnalytics/streamingjobs/read permission (roles/Reader on the job or resource group is enough, this blueprint only reads).
  • A Slack incoming webhook for alerts.
  • Azure Stream Analytics is a managed service with no self-hostable open-source emulator, there is no local container to start for it. This plugin calls the Azure Resource Manager API directly from the Kestra worker process, there is no sub-container taskRunner and no Docker network to join.

Secrets

  • AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_SUBSCRIPTION_ID: service principal credentials used by probe_job_status.

  • SLACK_WEBHOOK: Slack incoming webhook URL used by the alert tasks and the errors block.

    In Kestra OSS, set all five as base64-encoded environment variables, for example SECRET_AZURE_TENANT_ID, SECRET_AZURE_SUBSCRIPTION_ID, SECRET_SLACK_WEBHOOK.

Inputs

Input Type Default Allowed values
resource_group STRING stream-analytics-rg any resource group name
job_name STRING clickstream-processor any Stream Analytics job name
expected_job_state SELECT Running Running, Stopped
degraded_is_critical BOOL true true, false

Quick start

  1. Add the Azure and SLACK_WEBHOOK secrets.
  2. Set resource_group and job_name to a real job and run this flow manually.
  3. Read log_audit_summary for the real jobState and provisioningState.
  4. Set expected_job_state: Stopped for a job that is intentionally idle between runs.
  5. Enable the every_ten_minutes trigger.

How to extend

  • Loop this flow over a list of job_name values with io.kestra.plugin.core.flow.Loop to audit every Stream Analytics job in a resource group from one flow.
  • Chain a downstream task after CRITICAL that restarts the job through the Azure CLI, behind a manual approval task, since the Kestra plugin itself has no start or stop task for Stream Analytics.
  • Track jobState transitions over time in a Kestra KV entry to alert only when a job newly becomes Degraded, instead of every run it stays that way.

Pitfalls

  • jobState and provisioningState answer different questions: a job can show provisioningState: Succeeded while jobState is Stopped, that combination is healthy only if expected_job_state is set to Stopped for this job.
  • Degraded is a real, distinct jobState, not a sign the job stopped, a degraded job is still processing, just not keeping up or not fully healthy, decide deliberately whether that should page someone with degraded_is_critical.
  • This blueprint never starts, stops, or scales the job, there is no remediation task in this flow, the Stream Analytics plugin has no such task, the fix has to be applied in the Azure portal, CLI, or your infrastructure-as-code pipeline.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.