Every container's status, health check, CPU, and memory — tracked over time, alertable, correlated with its own logs, and predicted against its own history. No sidecar, no separate agent, no extra install.
| Container | Status | Health | CPU | Mem |
|---|---|---|---|---|
| api-gateway | running | healthy | 12% | 340 MB |
| worker-queue | running | unhealthy | 96% | 1.8 GB |
| postgres-1 | running | healthy | 34% | 512 MB |
| gochat-postgres-1 | restarting | unhealthy | 8% | 210 MB |
| Alert type | Fires when | Notes |
|---|---|---|
oom_killed | Container killed by the kernel for exceeding its memory limit | Distinguished from a normal exit or crash |
crash_looped | Repeated restart cycling detected | Fixed-threshold safety net — always fires regardless of baseline |
image_changed | The running image digest changed unexpectedly | Useful for catching unplanned deploys or drift |
unhealthy | Docker's own healthcheck reports unhealthy | Reads the healthcheck you already defined — nothing extra to configure |
cpu_threshold / mem_threshold | CPU or memory crosses a configured limit | Complemented by the ETA prediction below — a warning before the threshold, not just at it |
restart_rate_anomaly | Restart rate exceeds this specific container's own baseline | See "Restart-rate anomaly detection" below — the more interesting alert of the two restart-related types |
A single fixed threshold ("alert after 3 restarts") can't express that — different containers have wildly different normal cadences by design. So instead of a global number, Kllyroo computes an exponential-moving-average baseline of restart rate per container, learned from that container's own history, and flags a deviation from its own normal — not from an arbitrary constant.
The baseline starts from a short bootstrap period before going live, so a freshly deployed container isn't falsely flagged on day one just for having no history yet.
Every container gets the same trend-based "about to tip over" forecasting described in full on the Predictive Alerts page — applied here per container rather than per host.
HostConfig.Memory), not the host's total RAM, so an unlimited container correctly shows no ETA rather than a misleading one.Offices in India and the US — reach out and we'll get back to you.