Two tabs, one job: why error tracking belongs on your board

Every team I have worked on ran the same two tools. An error tracker in one tab — Sentry, Rollbar, Bugsnag, take your pick — and a project board in another. Jira, Linear, Trello, a wall of sticky notes. Both good at their job. Neither aware the other existed.

And every team did the same thing with them. Someone would spot a spike in the error tracker, read the stack trace, decide it mattered, and then retype it into the board. Title, severity, a link back to the exception, a guess at who should own it. Two minutes of clerical work, repeated forever.

The copy-paste is the bug

That handoff looks like process. It is actually a lossy queue with a human as the transport layer, and it fails in the ways lossy queues always fail:

• Things fall through it. An error nobody copies across is an error nobody schedules. It stays in the tracker, quietly incrementing a counter, until a customer finds it for you.
• State diverges immediately. The card gets closed. The error keeps firing. Nothing reconciles the two, so the board says "Done" while production disagrees.
• The context evaporates. What lands on the board is a title and a link. The breadcrumbs, the payload, the occurrence count — the things that made it diagnosable — stay behind in the other tab.
• It only runs when someone is looking. Triage happens when a human remembers to go and look at the error tracker, which is to say: after the incident.

None of that is a discipline problem. You cannot fix it with a better rota or a sterner retro. It is what happens when the system that detects work and the system that schedules work are two different systems.

What BugBoard does instead

There is no handoff, because there are not two systems.

An error reported through the SDK is a card. bugboard.critical(error) and it lands on the board with its stack trace, its payload, and its occurrence count attached — deduplicated against the ones already there, so the tenth occurrence increments a counter rather than opening a tenth card.

From there it is an ordinary card, because it is an ordinary card. Assign it. Comment on it. Drag it to Done. If it starts spiking, it escalates itself up the board without waiting for anyone to notice.

The whole product is that one idea. Detection and scheduling are the same job, so they should be the same tool.

The part I did not expect

I built this to stop losing bugs. What actually changed was which bugs got fixed.

When triage costs two minutes of retyping, you only pay it for errors you already believe are important — so the board fills with the loud, obvious ones, and the long tail of small papercuts never makes it across. When triage costs nothing, the papercuts show up too, and they turn out to be most of what your users actually run into.

The bugs you fix are the bugs you can see. It is worth being careful about what your tools let you see.

BugBoard has a free Hobby plan — 2 projects, 300 events per day, no card. Start there, or read the quickstart if you want to see the SDK first.