RO

Robusta

Kubernetes observability and automated troubleshooting

Monitoring & Status ★ 3.1k stars Medium setup MIT

Robusta enhances Prometheus alerts for Kubernetes with enriched context, automated troubleshooting, and notifications to Slack and other channels. It helps teams understand and respond to cluster issues faster.

Key features

  • Enriched Kubernetes alerts
  • Automated remediation playbooks
  • Slack and Teams notifications
  • Crash and OOM diagnostics

Pros & cons

Strengths

  • Makes alerts actionable
  • Strong Kubernetes focus

Trade-offs

  • Kubernetes only
  • Best with Prometheus already running

Robusta replaces

Last reviewed Sep 13, 2026 · 775 words

A pod gets OOM-killed at 03:14. With plain Alertmanager, the Slack message says KubePodCrashLooping and a namespace. With Robusta in the path, the same message carries the last 50 lines of the container's log, the pod's memory graph for the preceding hour, the Kubernetes events, and a note that the limit was 512 Mi and the process asked for more. That enrichment is the product. Everything else Robusta does is a variation on "when this alert fires, gather this and send it there", and whether you want it depends entirely on whether you already have alerts firing that you wish came with context.

Where it sits: after Prometheus, before Slack

Robusta does not collect metrics and does not replace Prometheus or Grafana. It receives alerts from Alertmanager via a webhook receiver, and it watches the Kubernetes API for changes on its own. Two components run in-cluster: robusta-runner, the Python process that executes playbooks, and robusta-forwarder, a kubewatch fork that streams API events to the runner. Sinks are the destinations: Slack, Microsoft Teams, Discord, Telegram, PagerDuty, OpsGenie, generic webhook, and the optional Robusta SaaS UI, which you can skip entirely.

If you have no Prometheus yet, the Helm chart can install kube-prometheus-stack for you with enablePrometheusStack: true. That is convenient on a fresh cluster and awkward on one where you already tuned a stack, in which case you leave it false and point Alertmanager at the runner. The Grafana vs Prometheus explainer covers how those pieces divide the job if the stack is new to you.

The install is a generated values file

pip install -U robusta-cli
robusta gen-config
helm repo add robusta https://robusta-charts.storage.googleapis.com
helm install robusta robusta/robusta -f ./generated_values.yaml \
  --set clusterName=homelab

gen-config asks about Slack (it runs an OAuth flow for the bot), whether to bundle Prometheus, and whether to enable the cloud UI, then writes generated_values.yaml. That file is your config forever after: sinks, playbooks, and per-alert overrides all live in it and you upgrade with helm upgrade -f. The 256 MB minimum is the runner's own footprint; the bundled Prometheus stack, if you take it, is a separate and much larger bill.

Playbooks: triggers, actions, sinks

A playbook in generated_values.yaml looks like this:

customPlaybooks:
  - triggers:
      - on_prometheus_alert:
          alert_name: KubePodCrashLooping
    actions:
      - logs_enricher: {}
      - pod_events_enricher: {}
    sinks:
      - main_slack_sink

Built-in enrichers cover logs, events, resource graphs, node status, Java heap dumps, and OOM diagnostics. The same team ships HolmesGPT, an open-source investigation agent that takes an enriched alert and runs a root-cause pass against your cluster using an LLM you supply, a hosted API key or a local model. It plugs into Robusta as another action and is optional; the deterministic enrichers are what you should install first, since they cost nothing per alert and never guess. Remediation actions exist too: restart a deployment, scale, delete a stuck pod, run a kubectl command, or hit a webhook. I keep automated remediation to the boring and reversible cases, such as restarting a deployment after a known-flaky alert, and leave anything that deletes to a human with the enriched message in front of them.

Who this is for

A team running production Kubernetes with Prometheus alerts they have stopped reading because each one costs 5 minutes of kubectl before it means anything. For that team, Robusta pays for itself on the first incident. It is also the open-source path to something close to what Datadog and PagerDuty sell as alert context, minus the SaaS bill.

For a single-node k3s homelab with 12 pods, it is the wrong tool. The homelab monitoring approach of an uptime checker and a Grafana board covers that scale, and Robusta's value only appears when the cluster is big enough that you cannot hold its state in your head. The catalogue's "Kubernetes only" con is literal: there is no Docker or bare-metal mode.

What I'd do

If you run Kubernetes in anger and already have kube-prometheus-stack: install Robusta with the bundled stack disabled, one Slack sink, and the default playbooks for CrashLooping, OOMKilled and node pressure. Live with that for 2 weeks before writing a custom playbook. Skip the SaaS UI unless you want its timeline view enough to send cluster metadata off-site. If you do not have Prometheus alerts yet, fix that first with the tools in the monitoring category; Robusta enriching nothing is 256 MB of idle Python.

Compare Robusta

27 head-to-head comparisons.

Similar monitoring & status apps