Alert on Loki Error Bursts with a Polling Trigger and Discord

Alert on log content without running a separate alert stack. This blueprint uses io.kestra.plugin.grafana.loki.Trigger to poll Loki every minute with the LogQL query {app="checkout"} |= "ERROR". When new matching lines appear, the trigger fires the flow with the fresh lines, their count, and the latest timestamp, and a Discord message goes out immediately. A state key remembers which lines were already seen, so a noisy error that keeps appearing in the lookback window never produces duplicate alerts.

How it works

1. The error_burst trigger (io.kestra.plugin.grafana.loki.Trigger) polls Loki every minute (interval: PT1M) with a five minute lookback (since: 5m) and up to 500 records per poll.
2. The stateKey: error_burst_checkout stores the last seen position in Kestra's state store, so only genuinely new lines start an execution.
3. When the trigger fires, alert_discord posts the new line count ({{ trigger.count }}) and the latest entry timestamp to Discord; the full matched lines stay on the execution as trigger outputs.
4. The errors block posts a distinct Discord alert if the notification itself fails, so alerting never degrades silently.
5. The trigger ships disabled: true; enable it once the secrets are in place.

What you get

• Log-content alerting with nothing more than Loki and Kestra, no Alertmanager, no ruler configuration, no separate alert pipeline.
• Stateful deduplication out of the box: reruns and overlapping lookback windows never refire on the same lines.
• The matched lines preserved on every execution for later inspection, not just a counter.
• A pattern that generalizes to any LogQL selector, panics, timeouts, OOM kills, or a specific customer id.

Who it's for

• Platform teams who ship logs to Loki but have not stood up Alertmanager or the Loki ruler.
• On-call engineers who want error alerts that carry the actual log lines, not just a metric threshold.
• Teams consolidating scheduling, alerting, and remediation flows in one orchestrator.

Why orchestrate this with Kestra

Loki stores the logs, but turning a LogQL match into an action still needs polling, deduplication state, retries, and a delivery channel. Kestra's Loki trigger handles all four declaratively, and because the alert is a regular flow, the reaction can grow beyond a message: open a ticket, restart a service, or snapshot surrounding context, all in the same YAML.

Prerequisites

• A reachable Loki instance ingesting logs with an app label (adjust the selector to your labels).
• A Discord incoming webhook for alerts.
• For authenticated or multi-tenant Loki, the trigger also accepts authToken (bearer token) and tenantId (sent as the X-Scope-OrgID header).

Secrets

• LOKI_URL: Loki base URL, e.g. http://loki.monitoring:3100.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the LOKI_URL and DISCORD_WEBHOOK_URL secrets to your Kestra namespace.
2. Adjust the LogQL query to a label selector and match string that exist in your Loki.
3. Set disabled: false on the error_burst trigger and watch the first alert arrive when a matching line lands.

How to extend

• Tighten or widen the polling cadence with interval and the lookback with since.
• Add a remediation task after the alert, for example restarting the failing service or scaling a deployment.
• Run one trigger per service by duplicating the flow with a different query and stateKey.
• Chain a QueryRange task in the flow to pull surrounding context around the matched lines, as shown in the incident context snapshot blueprint.

Links

• Grafana Loki plugin documentation
• LogQL documentation