Spike Detection

New-error notifications tell you when something breaks that has never broken before. They say nothing when something already broken suddenly starts happening a hundred times an hour — the error is not new, so no notification fires, and the shape of a bad deploy is exactly that.

Spike detection watches the rate instead of the novelty.

Turning it on

Settings → Monitoring → Error spike alerts. Switch on Spike detection and, if you want, change the Threshold multiplier.

It is off by default. A shop that has never looked at its error rate does not have a baseline worth alerting on, and the first week of any install is noisy by definition.

How a spike is decided

Errors are counted per hour as they arrive. Every ten minutes, the current hour's count is compared against the average of the previous 24 hours — and an hour in which nothing broke counts as zero, not as missing data, so a normally-silent site has a genuinely low baseline.

An alert fires when the count reaches the greater of the average multiplied by your threshold, and an absolute floor of 5 errors.

Your site's normal hour	Threshold	Alerts at
2 errors	×5	10 errors
20 errors	×5	100 errors
0 errors	×5	5 errors — the floor

The floor is what stops a quiet site paging you because one error became three. The multiplier is what stops a busy site staying silent through a tenfold jump. The threshold accepts 2–100 and defaults to 5.

The check runs every ten minutes rather than hourly, so a spike that starts at ten past the hour is reported by twenty past rather than at the end.

One alert per hour

At most one spike alert is sent per site per hour, regardless of how many times the check runs or how many instances are running it. A spike that lasts three hours is three alerts, one per hour — not one every ten minutes.

Where the alert goes

Through the channels you have configured, subject to your alert rules. Because a spike carries no severity, type or message of its own, a spike rule is only ever about which channels it reaches — there is nothing else to match on.

The alert names the hour, the number of errors in it, and the average it was measured against. It also appears live in the dashboard.

Reading the aftermath

The alert tells you a spike happened; it does not tell you what broke. Dashboard → Issues, sorted by occurrences over the same window, is where that answer is. If you have set a release on your builds, filter by it — a spike that starts at a deploy and is confined to one release is a regression, and the issue list badges it as one. See Error Tracking.