Skip to main content
Change Intelligence answers “what changed before this incident?” It collects deployment events from Kubernetes and CI/CD pipelines and surfaces them in the context of alerts and RCAs. Go to Changes in the sidebar.

How it works

Obsy tracks two types of change signals: Changes are correlated with alerts and incidents by:
  1. Timing — changes within 30 minutes before an alert get elevated relevance
  2. Service — changes to the same service as the affected one
  3. Namespace — changes in the same Kubernetes namespace
The RCA engine uses this correlation data as context for its analysis.

Kubernetes events (automatic)

Once a cluster is registered, Obsy’s Kubernetes watcher collects events automatically. No additional setup is needed. Events captured:
  • Deployment rollouts (new image, config change)
  • Pod crash loops and OOM kills
  • ConfigMap and Secret updates
  • Node pressure events (MemoryPressure, DiskPressure)
  • HPA scaling events

CI/CD webhooks

To capture deployment events from your CI/CD pipeline, send a POST to:
Payload:

GitHub Actions example

Add this step at the end of your deploy job:
Get your API token from Settings → API tokens.

Viewing changes

The Changes page shows a timeline of all recent changes across all services. Filter by:
  • Service — show only changes to a specific service
  • Environment — production, staging, or development
  • Source — kubernetes or ci/cd
  • Time range — last hour, 24 hours, 7 days
Changes correlated with an open incident or recent alert are highlighted.

Changes in RCA

When an RCA runs, the AI receives a list of changes in the 30 minutes before the triggering alert. If a deployment is the likely root cause, the RCA summary will reference it directly, e.g.:
“The payment-service deployment v2.4.1 (deployed 14:32 UTC by Jane Smith) introduced a misconfigured connection pool limit, causing the subsequent cascade of 503 errors.”