New to Kestra?
Use blueprints to kickstart your first workflows.
Monitor Kubernetes pod CPU spikes by polling Prometheus with Kestra. Groups alerts by application and sends Slack notifications when pods exceed the CPU threshold.
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).