Detection Engine

The alert already knows what broke.

223 deterministic signatures read your logs the way an experienced on-call engineer would — matching the exact pattern of a known failure and naming it, instead of scoring "how anomalous" a line looks and leaving you to translate that into an action.

Book a demo ← Back to platform overview

223signatures live today

20+stacks covered

5layers: web, app, DB, queue, OS

The problem with anomaly scores

A score tells you something's wrong. It doesn't tell you what.

Most monitoring tools train a statistical model on your metrics and flag whatever looks unusual. That catches real problems — but it hands you a number, not an explanation. "Anomaly detected, confidence 0.87" still leaves the actual diagnosis to a human at 3am.

Klyroo's signature engine works the other way. Instead of learning what's unusual, it's built from a library of what specific failures look like — the exact log line shape a MySQL connection-pool exhaustion produces, the specific pattern of a PHP-FPM worker being killed for running too long, the request signature of a webshell upload. When a signature matches, Klyroo already knows the cause, because the pattern is the cause.

How It Works

From raw log line to named root cause.

Agent ships the relevant log stream

The same lightweight agent that reports server metrics also tails the logs relevant to detected services on that host — web server, app runtime, database, queue — no separate log shipper to install or maintain.

Signature engine pattern-matches each line

223 deterministic rules run against incoming lines. A match isn't a probability — it's a specific, named failure condition with a pre-written fix attached.

Confidence-scored and categorized

Each hit carries a confidence score and a category (web / app / database / queue / OS / security) so you can triage by severity and layer, not just by timestamp.

Unmatched-but-suspicious lines don't get dropped

A line that doesn't match a known signature but looks worth a second look gets routed to the AI Chat layer for an LLM-generated explanation, instead of silently disappearing.

Related hits collapse into one incident

If a hit is part of a known cascade, causal correlation takes over from here and folds it into a single root-cause incident instead of a standalone alert.

Coverage

Representative signatures, by layer.

A sample of the 223 — the full library spans 20+ stacks across these five layers.

Layer	Signature	Detects	Typical fix
Web server	`nginx_502_bad_gateway`	Upstream refused or dropped the connection	Check upstream health before assuming it's nginx
Web server	`nginx_worker_exhausted`	Worker connections maxed under load	Raise `worker_connections` or add capacity
App runtime	`phpfpm_request_terminated_slow`	PHP-FPM killed a request for exceeding max execution time	Profile the slow endpoint; check for a blocking external call
App runtime	`node_event_loop_blocked`	Node's event loop stalled beyond threshold	Find the synchronous call blocking the loop
Database	`mysql_too_many_connections`	Connection pool exhausted	Raise `max_connections` or fix a connection leak
Database	`postgres_replication_lag`	Replica falling behind primary	Check replica I/O and long-running queries holding locks
Queue / cache	`redis_oom_evicting_keys`	Redis hit `maxmemory` and started evicting	Raise memory limit or fix an unbounded key pattern
Queue / cache	`rabbitmq_queue_backing_up`	Consumer rate falling behind publish rate	Scale consumers or find the stuck worker
OS / system	`disk_space_critical`	Filesystem nearing capacity	Clear logs/temp files or expand the volume
OS / system	`oom_killer_invoked`	Kernel killed a process for memory pressure	Identify which process spiked and why

Anatomy of a hit

Every match looks like this.

No score to interpret. A named signature, a plain-language explanation, and a fix — the same shape whether the layer is your web server, your database, or a security probe.

2026-07-21 09:04:11 [error] upstream timed out (110: Connection timed out) while reading response header from upstream

MATCH · nginx_502_bad_gatewayConfidence 92%

Nginx received a 502 because the upstream (PHP-FPM) took too long to respond.

Fix: check PHP-FPM's own logs first — this is almost always a downstream symptom, not an nginx problem.

Where We Stand

Scope, honestly.

What's covered

223 signatures across 20+ stacks and 5 layers
Every hit ships a specific, pre-written fix — not a generic recommendation
Confidence scoring so you can triage without reading every line
Unmatched suspicious lines get an LLM explanation instead of being dropped

What it isn't

Not a general-purpose log search tool — it's built to name known failure conditions, not index everything for ad-hoc querying
Coverage grows with the stacks we've curated signatures for; an unrecognized custom application won't get a named signature on day one
Not code-level tracing — it explains infrastructure and runtime failures, not slow lines inside your application logic

Pairs Well With

Related capabilities

See your own logs, explained.

Point one agent at a handful of your servers and watch the first signature match happen.

Book a 20-minute demo