Error alerts

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:

• Mute alerts — "I know about this; stop interrupting me." The issue stays on your board and keeps collecting events; you just stop getting emails about it. Right for a known bug you're already working on.
• Ignore — "this is unactionable; I never want to hear about it." Right for genuine noise — a browser extension's error, a third-party script you don't control.

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.