Alert LINE when a flow breaches its duration SLA

Catch slow pipelines before your stakeholders do. This Kestra blueprint broadcasts a LINE alert to your followers the moment a watched flow runs longer than its agreed duration Service Level Agreement (SLA), and stays completely silent the rest of the time. It solves a common monitoring gap: pipelines that never fail outright but quietly drift past their runtime budget, breaking downstream freshness guarantees without ever tripping a failure alert. The check is label driven, so one alerter can govern many flows that each declare their own threshold.

How it works

1. Each watched flow declares a native MAX_DURATION SLA that stamps the label sla: miss on any execution that exceeds its allowed duration. Fast runs are never labelled.
2. This flow's io.kestra.plugin.core.trigger.Flow trigger watches terminal executions in the company.team namespace, scoped by an io.kestra.plugin.core.condition.ExecutionNamespace condition (prefix: true).
3. An io.kestra.plugin.core.condition.ExecutionLabels condition filters that stream down to executions carrying sla: miss, so the alert fires only for genuine breaches.
4. The notify_sla_breach task (io.kestra.plugin.line.LineExecution) authenticates with channelAccessToken and posts a broadcast. It links the breaching execution via {{ trigger.executionId ?? execution.id }} and adds customFields (Owner, Action, Threshold) plus a customMessage naming the flow and namespace.

The duration check stays in the watched flow's SLA on purpose: a Flow trigger only exposes trigger.executionId, trigger.namespace, trigger.flowId, trigger.flowRevision, and trigger.state, not the upstream run's duration. Gating at the SLA source is the supported, reliable pattern.

What you get

• A LINE broadcast that fires only on real SLA breaches, never on healthy runs.
• One alerter that governs many flows, each with its own MAX_DURATION threshold.
• Hardened delivery: retry (constant, 5 attempts, 10s apart) and timeout: PT30S on the LINE call.
• A direct execution link so on-call can open the slow run and see its actual duration.

Who it's for

• Data platform and on-call teams who need to know when pipelines slow down, not just when they fail.
• SRE and operations engineers enforcing freshness and runtime SLAs across a namespace.
• Analytics teams whose downstream consumers depend on timely delivery.

Why orchestrate this with Kestra

LINE has no concept of your pipeline's runtime budget and cannot watch your executions. Kestra's event-driven Flow trigger reacts to terminal states across an entire namespace, the declarative MAX_DURATION SLA labels breaches at the source, and ExecutionLabels filters cleanly so you alert on signal, not noise. Built-in retry and timeout make the notification itself dependable, the whole setup lives in version-controlled YAML, and execution lineage links every alert straight back to the run that caused it. No cron or external scheduler can express "tell me when any flow in this namespace overruns its SLA."

Prerequisites

• A LINE Messaging API channel (a LINE Official Account with the Messaging API enabled).
• A LINE Channel Access Token with permission to broadcast messages.
• One or more flows in company.team that declare a MAX_DURATION SLA setting the label sla: miss on breach, for example:

sla:
  - id: maxDuration
    type: MAX_DURATION
    duration: PT15M
    behavior: CANCEL
    labels:
      sla: miss

Pick behavior: CANCEL (recommended, lands the run in CANCELLED) or behavior: NONE (keeps the natural SUCCESS state and only labels). The states list here (SUCCESS, WARNING, CANCELLED) supports both and deliberately omits FAILED so a companion failure monitor can own failures without double-alerting.

Secrets

• LINE_CHANNEL_ACCESS_TOKEN: the Channel Access Token used to authenticate to the LINE Messaging API and broadcast the alert. Store it as a Kestra secret and never hardcode the value.

Quick start

1. Create a Channel Access Token in the LINE Developers console for your Messaging API channel.
2. Add it to Kestra as the secret LINE_CHANNEL_ACCESS_TOKEN.
3. On each watched flow, add a MAX_DURATION SLA with your threshold (for example duration: PT15M) that sets the label sla: miss on breach.
4. Point the ExecutionNamespace condition at the namespace you want to govern and align states with your SLA behavior.
5. Update the Owner custom field and the customMessage, then deploy.
6. Run a flow that exceeds the threshold to confirm the alert fires, and a fast one to confirm it stays silent. You can run this flow manually as a smoke test, since executionId falls back to execution.id.

How to extend

• Add FAILED back to states (if you do not run a separate failure monitor) to also catch slow runs that failed.
• Route different namespaces to different LINE Official Accounts by cloning the flow with a new ExecutionNamespace prefix and token.
• Enrich customFields with run book links, severity, or the owning team derived from labels.
• Fan out to a second channel (Slack, email, PagerDuty) in the same flow so an SLA breach never goes unseen.

Links

• Kestra LINE plugin: https://kestra.io/plugins/plugin-line
• Workflow SLAs: https://kestra.io/docs/workflow-components/sla
• ExecutionNamespace condition: https://kestra.io/plugins/core/conditions/io.kestra.plugin.core.condition.executionnamespace
• LINE Messaging API broadcast: https://developers.line.biz/en/docs/messaging-api/sending-messages/#send-broadcast-message