Alert a QQ group on flow failures across a namespace

Centralized QQ failure alerting for an entire Kestra namespace using Tencent Cloud IM. A Flow trigger watches every execution under a configurable namespace prefix and, the moment any flow ends in FAILED or WARNING, pushes a structured alert to your on-call QQ users or groups with the originating flow id, namespace, final state, and a clickable deep link back to the failed execution in the Kestra UI. Deploy it once, cover every current and future flow in that namespace, and stop bolting per-flow notification tasks onto every pipeline.

How it works

1. A io.kestra.plugin.core.trigger.Flow trigger (on_failed_or_warning) listens for executions in states FAILED and WARNING matched by an io.kestra.plugin.core.condition.ExecutionNamespace condition with comparison: PREFIX (default namespace company).
2. When the condition matches, the notify_qq_on_failure task (io.kestra.plugin.tencent.qq.QQExecution) calls the Tencent Cloud IM REST API using url and token pulled from secrets.
3. The payload is built inline with Pebble, interpolating trigger.namespace, trigger.flowId, trigger.state, trigger.executionId, and the configured kestra_ui_url, then passed through | toJson so quotes, backslashes, and newlines in flow ids are escaped safely.
4. Recipients come from the qq_recipient_ids input (an ARRAY of STRING, defaults to oncall-primary and oncall-secondary) and are emitted as To_Account in the IM TIMTextElem message.
5. The single REST call is wrapped with timeout: PT30S and a constant retry policy (three attempts, ten seconds apart) so transient 5xx, 429 rate limits, or hung connections do not silently drop the page.

What you get

• One alerter that covers every flow under a namespace prefix, present and future.
• QQ messages with the failing flow id, namespace, final state, and a one-click deep link to the execution.
• Retries and a hard timeout on the IM call so transient errors do not eat the page.
• JSON-safe payload assembly via toJson for flow ids containing special characters.
• A clean separation: the alerter lives in the system namespace, away from business flows.

Who it's for

• Platform and SRE teams running Kestra for multiple business units that standardize on Tencent ecosystem tooling.
• On-call engineers in Tencent Cloud and APAC environments who already use QQ or Tencent Cloud IM for paging.
• Data and ML platform owners who want one declarative failure-alerting workflow instead of per-pipeline notification tasks.

Why orchestrate this with Kestra

Tencent Cloud IM and QQ do not know that a Kestra flow exists, let alone that one failed. Kestra's Flow trigger turns any execution state change into an event, with namespace-prefix conditions to scope what is alert-worthy. You get retries, timeouts, full lineage on the alert task itself, and declarative YAML you can version and review. Because the alerter reacts to other flows' executions rather than running on its own schedule, you deploy it once per monitored prefix and it stays in sync as new pipelines ship, something a cron-based monitor or per-flow notification task cannot do without ongoing maintenance.

Prerequisites

• A Tencent Cloud IM application with the REST API enabled and a valid UserSig signature for the admin identifier.
• The Tencent Cloud IM sendmsg REST endpoint URL for your SDKAppID (typically v4/openim/sendmsg).
• One or more QQ user or group identifiers to receive alerts.

Secrets

• TENCENT_IM_URL: the Tencent Cloud IM REST endpoint used to send messages, including SDKAppID, admin identifier, and (commonly) the usersig signature in the query string.
• TENCENT_IM_TOKEN: the IM authentication token or UserSig passed via the task token property. If your endpoint already carries usersig in the query string, keep whichever single auth mode your deployment uses.

Quick start

1. Add the TENCENT_IM_URL and TENCENT_IM_TOKEN secrets to your Kestra instance.
2. Edit the namespace value in the ExecutionNamespace condition to the namespace prefix you want to monitor (for example company). Deploy this alerter once per monitored prefix.
3. Set qq_recipient_ids to the QQ identifiers of your on-call responders.
4. Set kestra_ui_url to your instance base URL so alert links resolve correctly.
5. Deploy this flow, then trigger a failing flow in the watched namespace to confirm delivery.

How to extend

• Drop WARNING from the watched states if warnings are too noisy in your environment.
• Add a second QQExecution task to fan out to a different QQ group for WARNING versus FAILED severities.
• Pair this with a windowed digest blueprint for very high-volume namespaces to batch failures instead of one message per execution.
• Enrich the payload with trigger.labels, trigger.url, or last task name to route pages by team or service owner.
• Add a parallel Slack, Microsoft Teams, or PagerDuty task for multi-channel paging.
• Deploy multiple copies in the system namespace, one per monitored business prefix, to keep escalation policies separate.

Links

• Tencent plugin docs: https://kestra.io/plugins/plugin-tencent
• Flow trigger: https://kestra.io/docs/workflow-components/triggers/flow-trigger
• Tencent Cloud IM REST API: https://www.tencentcloud.com/document/product/1047