Robusta Documentation

Robusta is an AI-powered SRE agent designed to automatically investigate alerts and identify root causes. It is built on HolmesGPT and provides the following capabilities:

• Automatic investigation: Every alert undergoes AI-powered root cause analysis.
• Data source integration: Connects to existing monitoring, ITSM, cloud tools, and MCP servers to gather evidence.
• On-demand investigation: Allows users to chat with the agent by tagging HolmesGPT in Slack or Teams.
• Centralized management: Use the Robusta Platform to manage SRE agents, triage alerts, and review investigation timelines.

Robusta is available in three deployment models: SaaS, self-hosted, or open source.

Playbooks are deterministic rules used to respond to alerts and unhealthy conditions in a Kubernetes cluster. Each playbook consists of two main parts:

1. Trigger: A condition that defines when the automation runs (e.g., a specific Kubernetes event or Prometheus alert).
2. Action: Defines what the automation does (e.g., fetching logs, running a command, or creating a notification).

Playbooks operate like pipelines: Events enter Robusta $\rightarrow$ Triggers are checked $\rightarrow$ Matching triggers fire $\rightarrow$ Playbook actions execute in order $\rightarrow$ Findings (notifications) are sent to configured sinks.

The Mattermost sink is considered a legacy sink in Robusta classic. It is deterministic, meaning it forwards every notification unchanged to the destination.

For new setups, it is recommended to use HolmesGPT instead. HolmesGPT uses AI to investigate alerts, surface root causes, and escalate only actionable items, reducing notification noise.

Robusta Sinks are a legacy feature used to forward notifications to fixed destinations. Sinks are deterministic: they send every notification, unchanged, to the destination, requiring you to manually read and prioritize each one.

For new setups, it is recommended to use HolmesGPT instead. Unlike Sinks, HolmesGPT uses AI to investigate alerts, surface likely root causes, and escalate only what needs attention, resulting in fewer and more actionable notifications.

Setup Options:

• For alerts: Use Alerts Triage.
• For custom events: Use Triggered Workflows.

Robusta Classic is the original open-source alert engine that provides deterministic, rule-based enrichment. It uses configurable playbooks to automatically attach pod logs, resource state, and related events to alerts before routing them to notification channels like Slack, Teams, or PagerDuty.

Robusta Classic can be installed as part of the Agent and runs alongside HolmesGPT.

By default, Robusta tracks all changes to the following resources and sends them to the Robusta UI for correlation with Prometheus alerts and errors:

• Deployments
• DaemonSets
• StatefulSets

Note: These changes are not sent to other sinks (like Slack) by default to prevent spam. To selectively track specific changes in Slack, you must configure [Notification Routing].

In Robusta, triggers are the mechanism that detects changes (e.g., a pod update) and generates event objects. These event objects are then passed to your playbook action functions.

Lifecycle of a Robusta Event:

1. A resource (like a pod) changes.
2. The Kubernetes API Server notifies Robusta.
3. Robusta checks if any configured triggers (e.g., on_pod_update) are activated.
4. If activated, the trigger converts the API Server data into a concrete event object (e.g., PodEvent).
5. The event object is passed to all registered playbook actions.

Robusta allows you to send notifications to various destinations and route them intelligently based on alert attributes like type, namespace, severity, and more.

Key concepts include:

• Sinks: The destinations where notifications are sent (e.g., Slack, Teams, Email).
• Routing: Rules that determine which alerts are sent to which sinks.
• Grouping: A mechanism to thread related alerts together to reduce noise, particularly in Slack.
• Silencing: The ability to temporarily disable specific notifications.

Robusta playbooks can be executed automatically based on several event types. The supported trigger categories are:

• Kubernetes (API Server): Triggers based on Kubernetes events and changes.
• Prometheus and AlertManager: Triggers based on alerts from Prometheus or AlertManager.
• Helm Releases Monitoring: Triggers based on changes in Helm releases.
• Scheduled: Triggers based on a defined schedule (cron-like).
• Webhooks: Triggers via incoming HTTP webhooks.
• Manual Triggers: Triggers initiated manually by a user.
• ElasticSearch: Triggers based on ElasticSearch monitors.