Fastly Daily Traffic Digest to Slack

Edge traffic is where problems show up first, and where nobody looks until something breaks. This blueprint puts the numbers in front of the team every morning: io.kestra.plugin.fastly.stats.Stats pulls yesterday's window for one service with day-level bucketing, and Slack gets the three numbers that summarize edge health, requests served, cache hits, and errors. The full stats payload, with every field Fastly reports for the day, stays attached to the execution for anyone who wants to dig deeper.

How it works

1. daily_stats (io.kestra.plugin.fastly.stats.Stats) queries the service with from set to yesterday and to set to today, computed from the schedule date with a fallback to the execution start for manual runs, and by: day so the window collapses into a single datapoint.
2. The task's data output is keyed by service ID, holding a list with one entry per day bucket. The Slack payload extracts the requests, hits, and errors scalars from the single bucket with jq, keeping the JSON payload scalar-only.
3. notify posts the digest with the report date and a pointer to the execution for the full payload.
4. The errors block sends a distinct alert when the stats call fails, so a missing digest never goes unnoticed.
5. A disabled-by-default Schedule trigger delivers the digest at 07:00.

What you get

• Yesterday's edge traffic in the channel before the standup, with zero console logins.
• The three numbers that matter for a first read: volume, cache effectiveness, and errors.
• The complete Fastly stats datapoint preserved on the execution, bandwidth, status classes, and everything else the API returns for the day.
• A pattern that extends to any field Fastly reports by editing one jq expression.

Who it's for

• SRE and platform teams who own the CDN and want a daily pulse without building a dashboard.
• Web teams tracking cache hit behavior after releases and config changes.
• Engineering managers who want error counts surfaced where the team already reads.

Why orchestrate this with Kestra

The Fastly console has these numbers, behind a login, for whoever remembers to look. Kestra turns them into a push: a scheduled flow with retries, a scalar-safe notification, an execution history that doubles as a day-by-day archive of the raw stats, and an error path that makes a broken report as loud as a bad number. Adding a second service or a second channel is a copy of one task, not a new report to maintain.

Prerequisites

• A Fastly service and an API token able to read stats.
• A Slack incoming webhook for the digest channel.

Secrets

• FASTLY_API_TOKEN: Fastly API token with stats read access.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the two secrets to your Kestra namespace.
2. Execute the flow with your service_id and check the Slack digest against the Fastly console for the same day.
3. Set disabled: false on the daily trigger.

How to extend

• Quote more fields from the day bucket, such as bandwidth or status class counts, by adding jq expressions for the fields your team watches.
• Compare against the previous day by widening the window to two days and quoting both buckets.
• Aggregate across all services with io.kestra.plugin.fastly.stats.AggregateStats for an account-wide digest.
• Add a threshold check with io.kestra.plugin.core.flow.If that escalates the message when errors exceed a limit, as the error spike trigger blueprint does in real time.

Links

• Fastly plugin documentation
• Fastly stats API documentation