One bug is one issue — no matter how many users hit it
Every event is grouped into an issue by a fingerprint — a hash of the error's type, its top stack frame, and the event kind. The same bug across different users, sessions, and re-deploys collapses into one issue, so your board shows distinct problems, not a flood of duplicates.
One deliberate detail makes this hold up: the error message is never part of the fingerprint. Messages often carry user data — an email, an order ID — and if they fed the grouping, one bug would shatter into hundreds of near-identical issues. Crossdeck groups on the structural shape, so "cannot read property of undefined" is one issue whether it happened to Sam or to ten thousand people.
Open, resolved, regressed, ignored
An issue moves through four statuses. Open is live and unhandled. You mark one resolved when you've shipped a fix. You set ignored for noise you never want to see. And the important one: if a resolved issue fires again, it flips to regressed automatically.
Regressed is the loudest signal in the system, on purpose — a fix that didn't hold is exactly the thing you most need to know about, and it's worse than a brand-new bug because you thought it was handled. It jumps back onto your board the moment the first new event lands.
The board sorts itself toward what hurts most
Priority is computed on every event, from severity, the number of paying customers affected, distinct users hit, rate anomalies, and your category tags. So the list orders itself toward "what's hurting paying customers, fast" without you grooming it. You can pin a priority by hand when you know better — and Crossdeck never overwrites a manual priority.
And you don't have to read a stack trace to know what an issue is. Every issue page carries a "What this means" card — three short blocks, What broke, Who's affected, What to do, with a severity and confidence label — written for whoever runs the business. It's grounded only in that issue's own redacted state; it explains the evidence rather than guessing.
Top of the list is where you start
Open Issues. The regressed, high-priority issue affecting paying customers sits at the top — that's where you start. Open it, read the "What this means" card, use the context and readable trace from the last lessons, fix it, mark it resolved. If it ever comes back, the board will tell you loudly.
One issue, fingerprinted across 1,240 events — regressed after a "fix," high priority because paying customers are affected. Start here.