How it works
Obsy tracks two types of change signals:| Source | What it captures |
|---|---|
| Kubernetes events | Pod restarts, deployment rollouts, config map changes, node events |
| CI/CD webhooks | Deployment completions from GitHub Actions, GitLab CI, ArgoCD, Jenkins, or any CI/CD tool |
- Timing — changes within 30 minutes before an alert get elevated relevance
- Service — changes to the same service as the affected one
- Namespace — changes in the same Kubernetes namespace
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:GitHub Actions example
Add this step at the end of your deploy job: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 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.”