# Error alerts

Silent by default. Crossdeck interrupts you for one thing — a real user couldn't do something that matters — not for how loud an error is. The alerts you get are always worth opening, and a background bug firing a million times never reaches your inbox.

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

## Silent by default — you're interrupted by a failed attempt, not by volume

The promise is simple: Crossdeck stays quiet until a user actually couldn't do something. An error on its own — even an unhandled one, even a loud one firing a thousand times — does not email you if it broke no attempt. It's captured, grouped, and searchable on the board; it just isn't news. What reaches your inbox is a confirmed failed attempt: a function a real user tried, that Crossdeck can authoritatively say failed.

"Authoritatively" is the key word. An alert fires only on hard evidence — your app declared the outcome failed (the one-line track('publish', { outcome: 'failed' })), an owned outcome failed (a charge or a sign-in), or a request returned a terminal 5xx with no recovery. A statistical dip in a completion rate is shown on the board as an association, never emailed as a failure — because "associated with" is not "caused."

## Facts, coalesced — and the paying signal up front

Alerts go to the project owner's account email, and they're written as facts, not verdicts: "3 attempts at Publish failed today. All three captured this error. Here's where." — never "this error broke publishing." The error is shown as the evidence captured during the failed attempt; the conclusion is yours to draw.

Two things shape how loudly it lands. Paying customers come first: a confirmed failure by someone paying you is the walk-out-of-the-meeting email, and it says so — "2 paying". And alerts are coalesced: a burst of failures on the same function is one email, not a hundred, so a genuine incident is unmissable without ever flooding you. A 5xx that's retried and recovers is never counted — only a request that truly ended in failure pages you.

## 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 one thing: a real user couldn't do something that matters — and often, that they're paying you. A background error that broke no attempt never reaches you; it waits on the board, searchable, in case its damage surfaces later. To make more of your make-or-break functions alertable, add the one-line declared outcome from the Capture an error guide. That's the Errors course, complete.

a real user couldn't do it
 "3 attempts at Publish failed today — 2 paying. Here's the error captured during them." One coalesced, facts-led email. A background bug firing a million times: none.