# Error alerts

One email per new issue, then silence — unless something genuinely changes. The notification contract is built so the alerts you do get are always worth opening, and a runaway bug can never flood your inbox.

Source: https://cross-deck.com/university/error-alerts/
Verified Crossdeck University lesson — prose plus real, runnable code.

## One email per new issue, then silence by default

The promise is simple: one email when a new issue first appears, and then nothing — until the situation actually changes. Re-alerts fire only on a small set of events worth interrupting you for: a regression (a resolved issue came back), an escalation to high priority, or an issue that's been quiet for six-plus hours and then logs 100+ events.

And there's a hard ceiling so nothing can ever spam you: at most 4 emails per issue per rolling 24 hours. A bug firing a million times is still, at most, four emails — because after the first, more of the same isn't news.

## Where alerts go, and the one exception to the cap

Error-alert emails go to the project owner's account email, and there are five flavours — first occurrence, regression, escalation, still-happening, and spike. Each cites the source-map-resolved top frame when a map is available, so you can see where it broke without leaving your inbox.

One deliberate exception to the 4-per-24h cap: spike notifications are exempt. A genuine rate incident must always land, so it's never suppressed — but it can't runaway either, because a spike fires once per incident and physically cannot fire again until that incident recovers. The cap protects you from noise; the spike exemption protects you from missing a real fire.

## Two ways to go quiet — they mean different things

When an issue is too loud, you have two controls, and the difference matters:

Choosing the right one keeps both surfaces honest: your inbox stays signal-only, and your board reflects what's actually worth tracking.

## An inbox you can trust

With the contract doing its job, an email from Crossdeck means something happened that you'd want to know about — a new bug, a regression, a real spike. Everything else lives on the Issues board, ready when you go looking. You tune the rest from Errors → Settings. That's the Errors course, complete.

signal in, noise out
 One email for the new issue, one for the regression, one for the spike — capped at four a day. Everything else waits on the board.