A threshold asks one question: is this number bigger than the number I picked? A learned baseline asks a harder one: is this number unusual for this thing, at this time of week? Both are legitimate ways to alert on response time, and the marketing around the second has gotten loud enough to obscure a plain fact — they catch different failures, and neither replaces the other.
The Definition, Without the Sales Pitch
Threshold alerting is a rule you write. “Page me when response time exceeds two seconds.” It fires the same way at 3 a.m. on Sunday as it does during Monday’s peak, because the number doesn’t know what day it is.
Anomaly detection builds its rule from history instead. The system watches what your monitor normally does, derives an expected range from that record, and flags values that land far outside it. Nobody picks a number. The number is inferred, and it changes as the underlying behavior changes.
That’s the whole distinction. Everything else in the anomaly detection vs threshold alerting debate follows from one being static and authored, the other derived and moving.
What a Baseline Is Made Of
“Learned baseline” sounds vague enough to hide anything, so it’s worth being specific about what one actually contains. Ours is in beta at the time of writing, works like this, and the shape is typical.
For uptime monitors, FlareWarden computes an expected response-time range for each of the week’s 168 hours, roughly the 10th to 90th percentile, from that monitor’s own successful checks over the trailing six weeks. A slow Tuesday afternoon gets judged against other Tuesday afternoons rather than against a global average. Baselines refresh nightly.
For cron monitors, the baseline is the median duration of the last 50 completed runs plus an outlier-resistant measure of spread, so one freak run doesn’t poison it. At least 10 completed runs are needed before scoring starts.
Two design details matter more than the statistics. Down checks, checks inside maintenance windows, checks marked as false alarms, and previously flagged anomalies are all excluded from the calculation — otherwise today’s anomaly quietly becomes next week’s normal, and the system learns to accept the degradation it was built to catch. And there are absolute floors, so a two-second job that takes three seconds never gets flagged no matter how consistent it usually is.
The Honest Table
| Threshold | Learned baseline | |
|---|---|---|
| Setup | You pick a number | Nothing to pick |
| Catches | Breaches of a limit you care about | Drift away from this monitor’s own normal |
| Misses | Slow degradation that stays under the limit | Problems that were always there |
| Time to useful | Immediate | Days, unless history already exists |
| Fails by | Firing constantly, or never | Learning bad behavior as normal |
What Each One Genuinely Catches
Thresholds win when there is a real number. If your checkout times out at three seconds, three seconds is not an arbitrary choice — it’s a contractual fact about your system, and no amount of statistical sophistication improves on knowing it. Thresholds also win the moment a monitor is created, because they need no history.
Baselines win on drift. A site that has always answered in 300ms and now takes 1.1 seconds is in trouble, and every threshold set anywhere above 1.1 seconds is silent about it. This is the failure mode that motivates the whole category: the site is up, every check returns 200, uptime reads 100%, and it’s getting steadily worse. We wrote about that gap at length in why a website can be slow but not down.
Baselines also win on rhythm. Traffic has a shape (weekday mornings, Sunday nights, the batch job at 2 a.m.), and a single global number either tolerates the peak and misses the trough, or catches the trough and screams through every peak.
Where Baselines Genuinely Lose
Three limits, stated plainly, because a monitoring vendor telling you its clever feature has no downsides is selling something.
They can’t detect what has always been true. A baseline describes normal, not good. If your API has been slow since launch, the baseline learns slow, and it will never flag it. Only a threshold, or a person with an opinion, catches that.
They need history. Our learning ladder is explicit: days 0 to 3 collect data and score nothing, days 3 to 21 run a global expected range with no weekday and weekend separation, and full hour-of-week seasonality arrives around day 21. A monitor checking every 30 minutes fills those 168 buckets more slowly than one checking every minute. Monitors with existing history skip the wait, since the baseline is computed from data already collected.
They flag change, which is not the same as damage. Ship a genuine performance improvement and a sensitive baseline may flag the new, faster numbers as anomalous until it relearns. That’s the mechanism working correctly and still being annoying.
Our Actual Recommendation
Run thresholds on everything, and add a learned baseline only where drift would cost you something.
Thresholds are free, instant, and require no history, so there is no argument for skipping them. Add anomaly detection to the monitors where a slow slide matters: checkout, sign-in, the API your customers build against, the nightly job whose runtime creeping from 20 minutes to 90 means it’s about to collide with the next thing. Skip it on the marketing site, where a 200ms drift changes nothing.
One structural decision worth copying regardless of vendor: anomalies should not be incidents. In FlareWarden they never affect your uptime percentage, never open an incident, and never trigger cross-region validation. They’re a quieter parallel signal, deliberately, because a probabilistic hint routed through the same channel as a confirmed outage is how alert fatigue gets built. A signal that means “this looks unusual” and a signal that means “your site is down” should not arrive the same way.
The Question That Settles It
Before enabling anomaly detection on a monitor, answer this: if this number drifted 40% worse over three weeks and never crossed any limit I’ve set, would I want to know?
For most monitors the honest answer is no, and a threshold is the whole solution. For the handful where it’s yes, no threshold you can write will ever cover it — which is the entire reason the feature exists.
Key Takeaways
- Static versus derived is the only real difference — a threshold is a number you author, a baseline is a range inferred from the monitor’s own history.
- A baseline learns normal, not good — a service that has always been slow will never look anomalous, so thresholds remain necessary.
- Seasonality is the payoff — per-hour-of-week ranges judge Tuesday afternoon against other Tuesday afternoons instead of a weekly average.
- Exclusions decide whether it works — if flagged anomalies and downtime feed back into the baseline, the system learns to accept degradation.
- Keep anomalies out of your incident stream — a “this looks unusual” signal delivered like an outage alert trains people to ignore both.
Curious what your site’s normal actually looks like? Start monitoring free with FlareWarden — anomaly detection is in beta and available on every plan including the free one, no credit card required.