Statistical
Post-Change Regression
Updated Jul 28, 2026 · 1d ago
Checks whether a deploy, config change or scale event actually made things worse, by comparing the window after the change against the matched window before it — per service.
Example alert
Exact wording varies — the detector generates titles from the anomaly it finds. This is representative of what an alert looks like when it fires.
How it works
For each recent change event, compares a 30-minute before-window against a 30-minute after-window for the changed service, skipping a settling period so restart bursts and cold caches don't count as a regression. Absolute floors mean a rise from 0.01% to 0.1% stays silent despite being a 10x ratio, and the regression is re-checked at the end of the after-window so a burst that recovered is not reported. Learning period: 3 hours per service.
Availability
Runs on these tiers:
Want to see this detector firing in the live demo?
Open alerts in the sandbox →Related detectors
- Volume Anomaly
Detects spikes, drops, and flatlines in log volume vs daily and weekly baselines per service.
- Silence Detection
Catches services that stop logging when they normally log every N seconds. The most dangerous failure mode: no errors, just absence.
- Outlier Detection
Multi-dimensional outliers in log feature space. Catches subtle anomalies that single-axis thresholds miss.
- Numeric Field Anomaly
Discovers the numeric fields your logs carry — payment amounts, cache hit rates, queue depths, inference scores — and flags when one drifts from its baseline.
- Error Growth Forecast
Spots an error signature whose arrival rate is climbing and projects when it reaches a volume that matters — as a time range, before the incident, not after.