Feature · /anomaly-detection
異常検知
しきい値の調整をやめて、季節性を私たちに学ばせてください。
In one line
メトリクスごとの予測バンド、BOCPD変化点、多変量。
What you get
- Per-metric, per-signature forecast band (Prophet baseline, ETSformer for high-cardinality)
- Change-point detection (BOCPD) on every metric — surfaces structural shifts
- Multi-variate anomaly: 'CPU is fine, IOPS is fine, but their joint distribution is wrong'
- Tunable sensitivity per workload (alerts on day-to-day vs. month-to-month deviations)
- First-class support for seasonality (daily, weekly, business-day)
- Built-in feedback loop: thumbs-up / thumbs-down trains the per-tenant model
vs Datadog DBM
FAQ
How long until the model is useful?+
We have a useful baseline at 3 days, an excellent one at 14 days. Until then we fall back to robust EWMA so you still get alerts.
Can I bring my own model?+
Business+ plans expose a webhook for the detector — you can post anomaly verdicts from your own model.
Related reading
AI
Anomaly detection on database metrics: why thresholds fail and what works
A walk through forecast bands, change-point detection, multi-variate anomaly, and the seasonality math that makes 'p99 over 200ms' the wrong alert by default — with the Postgres example that broke our last threshold.
Postgres
Why your Postgres p99 latency lies — and what to track instead
p99 over 1m windows is the most-displayed and most-misleading number on every DBM dashboard. Here's the histogram math, the seasonality math, and a saner default.
Postgres
Postgres slow queries: 12 causes and how to find each one
A field-tested playbook for diagnosing a slow Postgres query in production — from missing indexes to plan flips to bloated tables — with the SQL to find each cause and the fix.