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.
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.
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%," Kllyroo 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.
| Asset type | ETA prediction | Baseline anomaly |
|---|---|---|
| Servers | CPU, memory, disk | CPU, memory, disk |
| Containers | CPU, memory | CPU, memory, restart rate |
| Kubernetes pods | Not yet — metrics are categorical today | Restart rate |
Offices in India and the US — reach out and we'll get back to you.