beehiivA customer emails to say checkout is broken. You open Sentry, and there it is. Two hundred events since lunch, unresolved, unseen.
Sentry caught it. Nobody was looking at Sentry.
What the board shows from Sentry
Sign in to Sentry and pick your unresolved issues. They land as a live list on your board, for one project or for all of them. Each form shows what the widget will say before you add it, or you can just ask your agent.
Put the list next to your Vercel deployments and a new error sits beside the deploy that shipped it. Put it next to revenue and signups, and if a bug is costing you, the error and the dip sit side by side.
The board doesn’t send alerts. It isn’t trying to wake you up at 3am, and Sentry’s own alerts already do that. It’s the screen you glance at between tasks, with the errors on it.
Where the data comes from
Sentry runs its own MCP server, and the board connects with Sentry’s sign-in. The sign-in is sealed on the board’s server and never shown again.
Sentry’s server can also update issues for agents that ask. The board never runs those tools. It only runs tools that read, so nothing in your Sentry organization changes because of it.
The list is read again while the board is open, on the schedule you pick. If a read fails, the widget keeps the last good list and says what went wrong and when. It never shows an error count it didn’t get from Sentry.
Why a board as well as Sentry
Sentry is where you dig into an error, trace by trace. That stays where it is.
What a board adds is the glance. Your unresolved issues beside the deploys, the revenue and the to-do list, in a place you already look at fifty times a day. With any luck, you spot the new one before a customer has to tell you.