# Rootly Kubernetes Integration: Cluster Events in Incidents

URL: https://rootly.com/integrations/kubernetes

> Send Kubernetes deployment, pod and node events to Rootly with kubewatch, link them to services, and surface what changed on every incident timeline.

1. [Home](https://rootly.com/)
2. [Integrations](https://rootly.com/integrations)
3. Rootly Kubernetes Integration: Cluster Events in Incidents

Published November 11, 2026

Rootly Kubernetes Integration: Cluster Events in Incidents

1. What the Rootly Kubernetes integration does
2. Resource types Rootly accepts
3. Connect a cluster to Rootly
4. Send deploys from CI as pulses
5. Get Kubernetes changes into Slack
6. How teams use Kubernetes with Rootly

### On this page

1. What the Rootly Kubernetes integration does
2. Resource types Rootly accepts
3. Connect a cluster to Rootly
4. Send deploys from CI as pulses
5. Get Kubernetes changes into Slack
6. How teams use Kubernetes with Rootly

Rootly pulls Kubernetes cluster events into incidents automatically. The Rootly Kubernetes integration uses [kubewatch](https://github.com/robusta-dev/kubewatch), an open-source cluster watcher, to forward events from deployments, pods, services, nodes and other resources to a webhook unique to your Rootly workspace. Each event becomes a pulse, Rootly’s record of a change, and pulses that match an incident’s services show up on its timeline. Responders see “what changed in the cluster right before this broke” without running `kubectl` against production. Setup is documented in the [Rootly Kubernetes docs](https://docs.rootly.com/integrations/kubernetes).

> **Setup docs:** step-by-step installation, the full configuration reference and troubleshooting are in the [Rootly Kubernetes integration docs](https://docs.rootly.com/integrations/kubernetes).

Kubernetes events are only part of the picture. Rollouts from your CI pipeline, `kubectl rollout` runs and Helm releases can also send pulses through the Rootly API or CLI, and container logs and crash metrics come from your monitoring tool, such as [Datadog](https://rootly.com/integrations/datadog) or Prometheus Alertmanager.

## What the Rootly Kubernetes integration does

- **Tracks cluster events in real time.** Deployment updates, pod scheduling and terminations, node condition changes, job failures, ingress and config changes arrive as pulses as they happen.
- **Links events to services.** Rootly matches each event to a service by the service’s **Kubernetes Deployment Name** field, so a deploy of `api-server` lands on incidents for the API service.
- **Puts the events in front of responders.** When someone opens an incident, Rootly shows the pulses that landed shortly before it, filtered by the incident’s services, environments and time window.
- **Posts changes to Slack.** A pulse workflow can post a message to a Slack channel when a matching pulse arrives, for example every production deployment.

## Resource types Rootly accepts

| Resource | Events |
| --- | --- |
| `deployment` | Creates, updates and deletes |
| `pod` | Scheduling, crashes and terminations |
| `replicaset`, `replicationcontroller`, `daemonset` | Scaling and status changes |
| `services`, `ingress` | Service and ingress rule changes |
| `job` | Batch job completions and failures |
| `node` | Readiness and condition changes |
| `namespace`, `persistentvolume` | Creation, deletion, binding and release |
| `configmap`, `secret`, `serviceaccount`, `clusterrole` | Configuration and RBAC changes |

Turn on only the types you want. Most teams start with deployments, pods, nodes and jobs, and leave `secret` and `configmap` off to keep noise down.

## Connect a cluster to Rootly

1. In Rootly, open the integrations page and select **Kubernetes**. Rootly generates a webhook URL and signing secret for your workspace.
2. Deploy kubewatch to the cluster with Helm or `kubectl`. Only its webhook handler is needed; Slack and other handlers can stay off.
3. Point kubewatch’s webhook handler at the URL Rootly generated:

`handler : webhook : url : "https://rootly.com/webhooks/kubernetes/YOUR_WEBHOOK_URL"`

1. Enable the resource types you want to track in the kubewatch configuration.
2. In Rootly, set the **Kubernetes Deployment Name** field on each service so events attach to the right service. The match is partial, so `api-server` matches any deployment whose name contains it.

Events start appearing as pulses once kubewatch is running. To limit scope, use kubewatch’s namespace filters.

## Send deploys from CI as pulses

Cluster events show that a rollout happened. A pulse from the deploy job says which version shipped, who shipped it, and links back to the build. Add one step to the deploy pipeline:

`rootly pulse create "Deployed checkout-web v2.14.1" \ --services=checkout-web \ --environments=production \ --labels= "version=2.14.1,commit=a1b2c3d"`

The same call works from GitHub Actions, GitLab CI, CircleCI, Jenkins or Buildkite through the [pulses API](https://docs.rootly.com/configuration/pulses). Tag every pulse with its service and environment; triage filters on both, so an untagged pulse won’t show up on the incident.

## Get Kubernetes changes into Slack

Pulses are silent context: they don’t page anyone or open incidents on their own. A [pulse workflow](https://docs.rootly.com/workflows/pulse-workflows) acts on them. Typical rules:

- Post every production deployment to the owning team’s Slack channel.
- Post node condition changes to the platform team’s channel.
- Open an incident when a pulse matches a pattern your team treats as urgent.

With alert workflows from your monitoring tool on the same services, responders see the alert, the change that preceded it, and the graph without leaving the incident.

## How teams use Kubernetes with Rootly

Platform teams usually run kubewatch once per cluster, send deploy pulses from CI, and set the deployment name on every service in Rootly’s catalog (or sync the catalog from Backstage or Cortex). When an alert opens an incident, the responder sees the last deploys and cluster changes for that service before anyone asks “did something just ship?”

Rootly runs incidents natively in Slack, Microsoft Teams and Google Chat. The Kubernetes integration is included on every Rootly plan; see [pricing](https://rootly.com/pricing). For the full set of integrations to connect alongside it, see [must-have integrations for incident management software](https://rootly.com/incident-response/integrations).

Ready to connect it? Follow the [Kubernetes setup guide on docs.rootly.com](https://docs.rootly.com/integrations/kubernetes).

## Frequently asked questions

### Does Rootly integrate with Kubernetes?

Yes. Rootly receives Kubernetes cluster events through kubewatch, an open-source watcher that forwards events from deployments, pods, services, nodes and other resources to a webhook unique to your workspace. Events appear as pulses on incident timelines and are linked to services by deployment name. The integration is included on every Rootly plan.

### Can Rootly pull Kubernetes deployment events into incidents automatically?

Yes. Kubernetes events become pulses, and Rootly shows the pulses that landed shortly before an incident, filtered by its services, environments and time window. A pulse workflow can also post matching events, such as production deployments, to a Slack channel.

### Does the Rootly Kubernetes integration collect container logs?

No. kubewatch forwards Kubernetes events, not container logs or metrics. Logs and crash metrics come from your monitoring tool, such as Datadog or Prometheus Alertmanager, whose alerts reach Rootly through their own integrations.

### How does Rootly link Kubernetes events to services?

Set the Kubernetes Deployment Name field on each Rootly service. Rootly matches events to services by partial name, so a service with the name api-server matches deployments whose names contain api-server.

### How do I reduce noise from Kubernetes events?

Enable only the resource types you need in kubewatch, for example deployments, pods, nodes and jobs, and leave secret and configmap events off. kubewatch namespace filters limit monitoring to specific namespaces.