New to Kestra?
Use blueprints to kickstart your first workflows.
Broadcast a LINE alert to your Official Account followers whenever any flow in a Kestra namespace fails, with retries, runbook link, and no manual polling.
Turn every flow failure in a namespace into an instant LINE alert. This Kestra blueprint watches all executions in the company.team namespace (and its sub-namespaces) and broadcasts a LINE Messaging API notification the moment any flow ends in a FAILED state. The message names the failing flow, carries the execution context, and links to your on-call runbook, so the engineer on duty can jump straight to the broken run instead of discovering the outage hours later. It solves the classic gap in production orchestration: failures happen quietly and nobody finds out until a downstream consumer complains.
on_namespace_failure trigger (io.kestra.plugin.core.trigger.Flow) listens for executions that reach the FAILED state.io.kestra.plugin.core.condition.ExecutionNamespace condition with prefix: true scopes the trigger to the company.team namespace tree, so only the flows you care about fire alerts.notify_followers task (io.kestra.plugin.line.LineExecution) posts to the LINE broadcast endpoint, delivering to every follower of your Official Account.customMessage is templated from trigger context ({{ trigger.flowId ?? flow.id }}, {{ trigger.namespace ?? flow.namespace }}) and includes a runbook URL, while customFields tag the alert with Environment, Team, and Severity.executionId resolves from {{ trigger.executionId ?? execution.id }}, so the alert links to the failing run, and the flow can also be run manually as a smoke test.retry (constant, 5 attempts, 10s apart) and timeout: PT30S.LINE has no native awareness of your pipelines: it cannot watch executions, react to failures, or retry a delivery on its own. Kestra closes that gap. The event-driven io.kestra.plugin.core.trigger.Flow trigger reacts the instant a flow fails rather than waiting on a cron, the task-level retry and timeout make sure a flaky LINE API call still lands the alert, and execution lineage ties every notification back to the run that caused it. Because the whole monitor is declarative YAML, one file covers every flow in the namespace, including ones added later, with no glue code to maintain.
company.team namespace whose failures you want to track.LINE_CHANNEL_ACCESS_TOKEN: the long-lived Channel Access Token used to authenticate against the LINE Messaging API and broadcast the alert. Store it as a Kestra secret, never hardcode it.LINE_CHANNEL_ACCESS_TOKEN.namespace in the ExecutionNamespace condition to the namespace you want to watch.customMessage, the runbook URL, and customFields to match your team and severity conventions.WARNING to the trigger states list if your team wants to page on non-fatal conditions too.system namespace and widen the namespace prefix to monitor the whole instance.customMessage with execution duration, start date, or labels pulled from trigger context.