New to Kestra?
Use blueprints to kickstart your first workflows.
Poll Prometheus every 5 minutes for Kubernetes pods over a CPU threshold, group spikes by application, and fire a structured Slack alert.
Monitor Kubernetes pod CPU usage with Prometheus and get noise-free Slack alerts when pods run hot. This blueprint polls a Prometheus instance every 5 minutes, evaluates a PromQL query against the container_cpu_usage_seconds_total metric to find pods exceeding a configurable CPU-core threshold, groups the offending pods by application so multi-replica deployments raise one alert instead of many, and posts a formatted message to Slack only when a spike is actually detected. It solves the common problem of CPU-overload alerting without standing up and maintaining Alertmanager, and keeps detection logic versioned alongside the rest of your orchestration pipelines.
every_5_minutes io.kestra.plugin.core.trigger.Schedule trigger runs the flow on a */5 * * * * cron.query_cpu_spikes (io.kestra.plugin.core.http.Request) calls the Prometheus /api/v1/query endpoint with a bearer token, sending a PromQL expression that sums per-pod CPU rate over a 5-minute window and filters to pods above inputs.cpu_threshold_cores.parse_spikes (io.kestra.plugin.scripts.python.Script) reads the Prometheus JSON response, applies the optional inputs.namespace_filter, groups pods by application name (stripping the generated hash suffix), and emits spike_count, spikes, app_groups, and has_spikes outputs.send_alert (io.kestra.plugin.core.flow.If) checks has_spikes. When true, format_and_alert builds a Slack message and slack_notification (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts it to the incoming webhook.Prometheus stores metrics but its own scheduler cannot run conditional, multi-step reactions: parse a query, branch on a result, reshape the payload, then notify. Kestra adds a declarative YAML pipeline with a built-in Schedule trigger, conditional If branching, retries, and full execution lineage, so every poll, parse, and alert is auditable. You get repeatable alerting without a separate Alertmanager deployment or glue scripts.
container_cpu_usage_seconds_total (for example via kube-state-metrics or cAdvisor)PROMETHEUS_TOKEN: bearer token sent in the Authorization header to query PrometheusSLACK_WEBHOOK_URL: Slack incoming webhook the alert is posted toPROMETHEUS_TOKEN and SLACK_WEBHOOK_URL secrets to your Kestra instance.prometheus_url, cpu_threshold_cores, and namespace_filter inputs (or accept the defaults).