Weekly Capacity Digest from Prometheus to Slack

Capacity planning fails when the data lives only in dashboards nobody opens. This blueprint pushes one number into the channel where decisions happen. Every Monday, io.kestra.plugin.prometheus.Query evaluates avg(rate(process_cpu_seconds_total[7d])) with fetchType: FETCH_ONE, returning a single row whose scalar value flows straight into a Slack message. The team sees the seven-day CPU average without opening Grafana, and the execution history becomes a weekly log of the trend.

How it works

1. weekly_cpu (io.kestra.plugin.prometheus.Query, fetchType: FETCH_ONE) runs the PromQL aggregation against Prometheus and exposes the single result row as {{ outputs.weekly_cpu.row }}.
2. notify interpolates the scalar value from the row into a Slack message, keeping the JSON payload free of complex objects.
3. The errors block posts a distinct Slack alert when the query or the notification fails, naming the flow and execution.
4. A disabled-by-default Schedule trigger sends the digest every Monday at 08:00.

What you get

• A weekly capacity number delivered where the team already reads, with zero dashboard visits.
• PromQL evaluated by Prometheus itself, so the digest always matches what Grafana would show.
• A durable record of every digest in Kestra's execution history.
• A one-line query swap to report on memory, disk, request volume, or anything else Prometheus scrapes.

Who it's for

• Platform teams running a weekly capacity or reliability review.
• Engineering managers who want a trend signal without maintaining another dashboard.
• SRE teams turning ad hoc Grafana screenshots into a repeatable report.

Why orchestrate this with Kestra

Prometheus answers the question; Kestra makes the answer show up on time. The schedule, the query, the message, and the failure alert live in one version-controlled YAML file, and every digest that ever went out is auditable in the execution history. Adding a second metric or a second channel is a task, not a new cron job.

Prerequisites

• A Prometheus server reachable from your Kestra instance, scraping targets that expose process_cpu_seconds_total.
• A Slack incoming webhook for the digest and failure alerts.
• The Query task supports HTTP basic auth through its username and password properties if Prometheus sits behind one.

Secrets

• PROMETHEUS_URL: base URL of the Prometheus server, e.g. http://prometheus:9090.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the PROMETHEUS_URL and SLACK_WEBHOOK_URL secrets to your Kestra namespace.
2. Execute the flow once and confirm the Slack message carries a plausible CPU average.
3. Adjust the PromQL to the scope you care about and set disabled: false on the weekly trigger.

How to extend

• Add more Query tasks for memory or disk, for example avg(node_memory_MemAvailable_bytes), and interpolate each scalar into one digest message.
• Narrow the aggregation with label matchers, such as avg(rate(process_cpu_seconds_total{job="api"}[7d])), for a per-service digest.
• Use the time property to evaluate the query at a fixed point, for example the end of the previous week, for consistent reporting windows.
• Pair with the Prometheus SLO gate blueprint to act automatically when the numbers cross a threshold.

Links

• Prometheus plugin documentation
• PromQL documentation