Kubernetes

One cause, not seventeen symptoms.

A cluster is where alert storms are born. One node runs out of memory and every workload on it dies at once — this is the case promotion was built for, and where SaviourOps goes deepest.

Request early access

7 workloads restarted together on ip-10-0-1-23

Likely node memory pressure · dominant reason OOMKilled

Collapsed into the callout above

checkoutOOMKilled14:02:11

cartOOMKilled14:02:19

recommendationOOMKilled14:02:24

currencyEvicted14:02:31

shippingOOMKilled14:02:38

emailEvicted14:02:44

adOOMKilled14:02:51

Storm collapse

The grouping is stricter than it looks, which is the point — a collapse rule that fires too easily is just a different kind of noise.

Node storms: Three or more distinct workloads failing within thirty minutes on the same node collapse into one callout, with the cause named from the dominant reason — memory pressure for OOMKilled, resource pressure for evictions.
Workload identity: Workloads are keyed by root owner, so five failing pods of one Deployment count as one symptom. A thrashing ReplicaSet cannot inflate the count.
Systemic storms: Workloads failing for the same reason across two or more nodes collapse separately — ImagePullBackOff across four namespaces reads as a registry problem, not four unrelated deployment failures.
Cluster verdict: The overview opens with a plain sentence: all quiet with a workload and node count, or what needs attention and for how long.

What changed

Drift is what makes a likely-cause verdict possible at all. Without a change history there is nothing to correlate a failure against.

Rollout history: Per-workload image changes over time, which is the first thing the verdict engine checks.
Manifest versions: Successive versions of a workload's manifest, so a configuration edit is as visible as an image bump.
Live manifests: The current manifest for any resource, fetched without leaving the incident.
Image inventory: Every image running in the cluster, and where.
Config dependencies: Which workloads depend on which ConfigMaps and Secrets — so a config change has a visible blast radius before it has an outage.

Topology and workloads

Cluster summary and nodes: Capacity, pressure and counts, refreshed from the agent rather than polled from the API server by your browser.
Resource ancestry: Walk a failing pod up to its Deployment and back down to the node it landed on.
Workload metrics: CPU, memory and restart behaviour per workload, with an overview series for the shape over time.
Workload errors and DNS: Errors and DNS events attributed to the workload that caused them.
Service exposures: What is actually reachable, discovered rather than declared — with a service-discovery summary across the cluster.
Events and anomalies: Cluster events with an error summary, and detected anomalies surfaced against the workloads they affect.

The agents

Two of them, installed with one command each. No application code changes and no SDK in the request path.

Cluster agent: Watches events, topology, images, manifests and service exposures, and reports anomalies it detects locally.
eBPF node agent: Runs on every node and collects process, connection, HTTP, DNS and database-query events straight from the kernel, plus container resource metrics and crashes.
Synthetic traces: Traces derived from eBPF for services that emit no telemetry of their own, correlated alongside real OTLP traces.
Scoped API keys: Generated per cluster, listable and revocable, so removing a cluster's access does not mean rotating everything.

Find out how much of your paging was noise.

Connect one cluster and watch a week of alerts sort themselves into the handful that actually mattered.

Request early access