Incident Engine

One incident, not five pages.

When a database exhausts its connection pool, everything downstream lights up too — the app times out, the gateway starts returning 502s. Kllyroo's causal engine knows which of those alerts is the cause and which are just symptoms, and shows you one incident instead of a wall of noise.

← Back to platform overview

Why not just cluster alerts?

Co-occurrence isn't causation.

Plenty of tools group alerts that fire close together in time and call it "correlation." That catches obvious cascades but also produces false groupings — two unrelated issues that happened to overlap get bundled, and a real cascade with an unusual delay between steps gets missed.

Kllyroo instead uses a hand-curated causal graph: each of the 223 root-cause signatures is tagged with its known upstream and downstream relationships ahead of time. When multiple linked signatures fire on the same asset (or a related one) inside a correlation window, the engine walks the graph back to the earliest node in that specific chain and presents it as the root cause — with the rest attached as effects, not separate incidents.

The rules are deterministic and inspectable, not a black-box score. That matters for trust: your team can see exactly why Kllyroo called something the root cause, not just that a model was 87% confident.

Example

Two different cascades, same engine.

Signal timeline — server-13

09:04:11 — mysql_too_many_connections

09:04:19 — phpfpm_request_terminated_slow

09:04:26 — nginx_502_bad_gateway

DB pool exhausted → PHP-FPM backs up → Nginx 502s

Root cause: mysql_too_many_connections. Fix the connection leak; the downstream alerts clear automatically.

Signal timeline — cache-node-4

14:22:03 — redis_oom_evicting_keys

14:22:40 — cache_miss_rate_spike

14:23:15 — mysql_slow_query_surge

Redis evicting keys → Cache miss storm → DB overloaded

Root cause: redis_oom_evicting_keys. Raise Redis's memory limit — the database load is a symptom, not the disease.

How It Works

From three alerts to one verdict.

Signatures fire independently

Each root-cause signature detects and fires on its own — the correlation layer doesn't change detection, it changes presentation.

The causal graph is checked

Every signature carries a pre-defined set of known upstream/downstream relationships. When two or more linked signatures fire within the correlation window on the same or a related asset, they're candidates for the same incident.

The graph is walked to the earliest node

Among the candidates, the one with no known upstream cause in the group is named the root cause. Everything else in the chain is attached as an effect.

One incident, one fix, full reasoning attached

You get a single incident record with the root-cause signature, the effect chain, and the fix — plus the reasoning, so the pattern is visible, not just the verdict.

Where We Stand

Scope, honestly.

What's covered

Deterministic cause → effect rules across the signature library
Every correlation ships with its reasoning, not just a grouped list
Works across asset types — a database issue on one host can be linked to app symptoms on another

What it isn't

Not an auto-discovered dependency graph — the causal relationships are hand-curated per signature pair, not inferred from your specific topology
A cascade between two signatures we haven't yet mapped a relationship for will still show as separate alerts
Correlation depth grows as signature coverage grows — see Root-Cause Signatures for what's covered today

Pairs Well With

Related capabilities

Get In Touch

Reach us directly.

Offices in India and the US — reach out and we'll get back to you.