Catching error spikes early with anomaly detection

Every error-tracking setup eventually hits the same wall: you set a threshold — "alert me if errors cross 50 in an hour" — and it's wrong half the time. Fifty errors is a quiet afternoon for one endpoint and a five-alarm fire for another. Worse, the spike that actually hurts you is often a brand-new error appearing ten times when it has never appeared at all. That's the case static thresholds miss. Anomaly detection takes a different approach: instead of one fixed number, it learns what normal looks like for your app and alerts when reality deviates from it. This post explains why thresholds fall short, how anomaly detection works, and how to use it without drowning in noise.

Why static thresholds break

A fixed threshold assumes traffic is flat. It never is. Your error counts breathe with daily and weekly cycles — busy at lunchtime, dead at 3 a.m., heavier on weekdays. Pick a threshold high enough to survive the lunch peak and you'll sleep through a 3 a.m. outage that's small in absolute numbers but huge relative to a normally-silent night. Pick it low enough to catch the quiet hours and you'll get paged every busy afternoon. There's no single number that's right at every hour of every day, which is exactly why threshold alerts get muted.

What anomaly detection does instead

Anomaly detection builds a model of your baseline — the expected range of error volume for this app at this time — and watches for departures from it. The key shift is from absolute to relative: it doesn't ask "are there more than 50 errors?" It asks "is this far more errors than we'd expect right now?"

That reframing catches two things thresholds miss:

• A small absolute spike at a quiet time — ten errors at 3 a.m. when the baseline is near zero.
• A brand-new error — a fingerprint that has never been seen suddenly appearing, which is anomalous by definition regardless of count.

Baselining "normal"

To know what's abnormal, the system needs a sense of normal. It looks at your recent history and the shape of your traffic to estimate an expected range for the current window, then compares the live rate against it. When the live rate pushes outside that range, it's an anomaly. Because the baseline moves with your real patterns, the same deviation that's ignored during a known peak becomes a signal during a lull. You get sensitivity where it matters without false alarms where it doesn't.

Pair it with grouping, not against it

Anomaly detection is strongest on top of good grouping. If a thousand identical errors are rolled into one fingerprinted issue, a spike in that issue is meaningful and a spike in new issues is meaningful — and both are easy to detect. Without grouping, a single noisy error can look like a flood and bury the genuinely new problem. Lookout groups errors by fingerprint first, then watches for anomalous behavior across issues, so the signal you get is "something changed," not "the same known error is still happening."

Use it alongside threshold rules

Anomaly detection isn't a replacement for every alert — it's a complement. Keep explicit threshold rules for the cases where you know the line ("any payment failure pages on-call immediately"), and let anomaly detection cover the unknowns — the spikes and novel errors you didn't think to write a rule for. Together they cover both the failures you predicted and the ones you didn't.

Wrapping up

Static thresholds force one number onto an app whose traffic is anything but constant, so they either cry wolf or stay silent when it counts. Anomaly detection learns your baseline and alerts on real deviation — catching small-but-significant spikes and brand-new errors before users feel them. Layer it over fingerprint grouping and keep your hard threshold rules for the known-critical cases. Put anomaly detection on your app free — 10,000 events a month, one project, no credit card.