Schedule icon
Request icon
Script icon
If icon
SlackIncomingWebhook icon

Monitor Kubernetes Pod CPU Spikes with Prometheus and Send Grouped Slack Alerts

Monitor Kubernetes pod CPU spikes by polling Prometheus with Kestra. Groups alerts by application and sends Slack notifications when pods exceed the CPU threshold.

Categories
Infrastructure

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.

How it works

  1. The every_5_minutes io.kestra.plugin.core.trigger.Schedule trigger runs the flow on a */5 * * * * cron.
  2. 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.
  3. 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.
  4. 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.

What you get

  • Continuous, 5-minute CPU-spike detection across one or all namespaces
  • Application-level grouping so a busy deployment produces a single line, not one alert per replica
  • Alerts that fire only on real threshold breaches, cutting notification noise
  • A configurable threshold and namespace filter exposed as flow inputs
  • Full run history and logs for every poll, including quiet runs

Who it's for

  • SRE and DevOps teams running Kubernetes who want lightweight CPU alerting
  • Platform engineers who prefer alerting logic co-located with their pipelines
  • On-call teams managing multi-tenant clusters that need namespace-scoped routing

Why orchestrate this with Kestra

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.

Prerequisites

  • A reachable Prometheus instance scraping container_cpu_usage_seconds_total (for example via kube-state-metrics or cAdvisor)
  • A Slack incoming webhook URL
  • Kestra with the Python script and Slack plugins available

Secrets

  • PROMETHEUS_TOKEN: bearer token sent in the Authorization header to query Prometheus
  • SLACK_WEBHOOK_URL: Slack incoming webhook the alert is posted to

Quick start

  1. Add the PROMETHEUS_TOKEN and SLACK_WEBHOOK_URL secrets to your Kestra instance.
  2. Set the prometheus_url, cpu_threshold_cores, and namespace_filter inputs (or accept the defaults).
  3. Run the flow once manually to confirm the query and Slack delivery work.
  4. Enable the schedule and let it poll every 5 minutes.

How to extend

  • Add memory and network spike detection in the same run by sending extra PromQL queries.
  • Log every CPU reading to a database or object store for trend analysis.
  • Escalate persistent spikes to PagerDuty or email after repeated alerts.
  • Parameterize the cron and threshold per environment using flow inputs or labels.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.