Home/ Platform/ Predictive Alerts
AI-Assisted Detection

A warning before the page fires.

Two mechanisms, both learned from your own history rather than a fixed number you have to tune: ETA-to-threshold forecasting that projects when a metric will tip over, and baseline anomaly detection that judges a value against what's normal for that specific resource.

Book a demo ← Back to platform overview
2mechanisms: ETA & anomaly baseline
5 minforecast horizon — honest, not hours
3σoutlier clipping on every baseline
Mechanism One

ETA-to-threshold prediction.

A least-squares trend line is fit over a recent window of history for the metric, then projected forward. If the projected crossing of a threshold falls inside a short horizon, that's the alert.

ETA prediction — worker-queue
PREDICTED · cpu_eta_risk~4 min out
CPU is trending toward 90% at current rate — projected to cross in about 4 minutes.
Fix: check for a stuck consumer or queue backlog before it starts dropping jobs.
Stated plainly: this is a short-range, "about to tip over" warning — not an hours-long capacity forecast. The prediction window is capped intentionally, because a trend line fit on a few minutes of data stops being trustworthy the further out you project it.
Mechanism Two

Self-learning baseline anomaly detection.

Every metric on every resource gets its own baseline — an exponential moving average with Winsorized 3-sigma clipping, so a single outlier spike doesn't permanently drag the baseline off course.

Rather than "alert above X%," Klyroo asks "is this unusual for this specific resource?" A database that normally sits at 70% CPU shouldn't page every hour; a queue worker that normally idles at 5% absolutely should page if it jumps to 60%. A fixed threshold can't express either case correctly at the same time — a self-learning baseline can.

New resources go through a short bootstrap period before their baseline is considered established, so a container or pod deployed five minutes ago isn't judged against a baseline of essentially no data.

Restart baseline — gochat-postgres-1
ALERT · restart_rate_anomalygochat-postgres-1
Restart rate is well above this container's own baseline — 5 restarts in 15 min vs. a typical 0.1.
Fix: check the container's own logs for the crash reason — this is a real deviation, not noise.
Where It Runs Today

Coverage by asset type.

Asset typeETA predictionBaseline anomaly
ServersCPU, memory, diskCPU, memory, disk
ContainersCPU, memoryCPU, memory, restart rate
Kubernetes podsNot yet — metrics are categorical todayRestart rate
Where We Stand

Scope, honestly.

What's covered

  • ETA-to-threshold prediction for CPU and memory on hosts and containers
  • Self-learning EMA baselines with 3-sigma outlier clipping — no manual thresholds to tune
  • Restart-rate anomaly detection on containers and Kubernetes pods
  • Every predictive alert ships with a plain-language reason, not just a number

On the roadmap

  • Disk and network ETA/anomaly detection for containers — not collected as per-container metrics today
  • CPU/memory ETA and anomaly detection for Kubernetes pods — needs a numeric metrics pipeline we haven't wired in yet
  • The forecast horizon stays intentionally short — long-range capacity planning is a different, harder problem we haven't built
Pairs Well With

Related capabilities

Container & Kubernetes

Container Intelligence

Where the ETA and anomaly detection above are applied per container.
Container & Kubernetes

Kubernetes Monitoring

Restart-rate baselining for pods, and where CPU/memory prediction is headed next.
Incident Engine

Causal Correlation

A predicted alert can become the earliest node in a cascade, warning before it starts.

Get the warning before the incident.

See a real ETA prediction fire against your own history.

Book a 20-minute demo