Fastly Edge Error Spike Alert with the Stats Trigger

When the edge starts serving errors, users see it before your origin dashboards do, because the CDN sits in front of everything the origin monitoring watches. This blueprint puts the pager at the edge itself: io.kestra.plugin.fastly.stats.StatsTrigger polls the service's stats and fires an execution the moment the errors field crosses a threshold over a rolling five minute window. The flow logs the measured value and pages Discord with the number, the field, and the threshold, edge-side error detection without deploying a monitoring stack next to the CDN.

How it works

1. on_error_spike (io.kestra.plugin.fastly.stats.StatsTrigger) polls every minute (interval: PT1M) and evaluates the errors field over a PT5M window against a threshold of 100. It ships disabled: true; set your service ID and enable it to arm the pager.
2. When the threshold is crossed, the trigger starts one execution and exposes the measured value, the field it watched, and the threshold it compared against.
3. log_breach (io.kestra.plugin.core.log.Log) writes those three values into the execution history, making spikes queryable after the fact.
4. page_team (io.kestra.plugin.discord.DiscordIncomingWebhook) posts the same numbers to the on-call channel, so the responder starts from the measurement.
5. The errors block raises a distinct Discord alert if the flow itself fails, because a silent pager is the worst failure mode an alert can have.

What you get

• Edge-side error detection with no Prometheus, no exporter, and no agent, the trigger polls Fastly's own stats API.
• Alerts that carry the measured value and the threshold, not just "something is wrong".
• A permanent record of every spike in Kestra's execution history, ready for postmortems and trend questions.
• One YAML file that is both the detection rule and the response, versioned together.

Who it's for

• SRE and on-call teams responsible for services fronted by Fastly.
• Platform teams who want CDN-layer alerting without adding another monitoring system to run.
• Teams whose origin monitoring keeps missing incidents that only manifest at the edge.

Why orchestrate this with Kestra

Detection is only useful when it is wired to a response. The stats trigger gives Kestra the detection, and everything after the threshold crossing is ordinary flow machinery: notifications with the trigger's outputs, retries on the webhook call, an execution per incident, and room to grow the response, fetch context stats, open a ticket, or start a mitigation flow, without touching the detection rule.

Prerequisites

• A Fastly service and an API token able to read stats.
• A Discord webhook routed to the on-call channel.
• A threshold calibrated to your traffic; 100 errors in five minutes is a starting point, not a recommendation.

Secrets

• FASTLY_API_TOKEN: Fastly API token with stats read access.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the two secrets to your Kestra namespace.
2. Replace the placeholder serviceId on the trigger with your Fastly service ID and tune threshold to your traffic.
3. Set disabled: false on the trigger to arm it.
4. Verify the wiring by temporarily lowering the threshold below your normal error count and watching the Discord alert arrive.

How to extend

• Watch a different signal by changing field, or clone the trigger in a second flow for bandwidth or request anomalies.
• Add io.kestra.plugin.fastly.stats.Stats as a first task to attach a fuller picture of the window to the execution.
• Escalate beyond chat with PagerDuty or Opsgenie tasks when the measured value is far above the threshold.
• Pair with the emergency purge-all blueprint when the spike traces back to poisoned cached content.

Links

• Fastly plugin documentation
• Kestra triggers