Sentry never misses an error. The hard part is turning that flood into tasks people will actually take on. Fresh error types land beside ones that have been climbing for days. Some already have a GitHub issue, some do not, and you cannot tell which without digging. By the time an engineer finds a free hour to sort through it, the pile is so long that sorting it is a project in itself. Most weeks that hour never comes, and the pile keeps growing.

So we gave the job to an agent on Machine that tidies the backlog every hour. It reads Sentry as it stands right now, groups the new and spiking errors, sees which already have a GitHub issue, and drafts an issue with the stack trace and impact for the ones that do not. Then it posts a summary in Slack. This is housekeeping, not paging: it never wakes anyone up, and it never declares anything fixed.

The problem

Errors pile up in Sentry faster than anyone gets round to them. A few are brand new. Others have ticked along unresolved for weeks at a slow, even pace. Others took off after this morning's deploy. Deciding which ones deserve an engineer, and whether someone already opened a GitHub issue for them, means reading the entire list by hand. That is precisely the chore that slides every time something more pressing turns up.

The usual fixes shift the pile around instead of tidying it. Opening a GitHub issue for every Sentry error buries your tracker in duplicates and one-off blips nobody will touch. Treating Sentry itself as the record means the backlog is only as fresh as the last time someone looked at the dashboard. On-call tools solve the other half of the problem, the single loud alert happening now, not the quiet heap of errors that never paged anyone but still deserve a decision.

What we built

Once an hour, a cron job on Machine wakes the agent. It starts a new session, a fresh cloud computer (a sandbox) for that run alone, which can read Sentry but not change it. The agent collects errors that are new or that are firing well above their recent baseline, and groups them by fingerprint. Before doing anything with an error, it searches our GitHub repo for an issue that already covers it. For the biggest offenders with no issue yet, it drafts one with the stack trace and the impact: how many events, how many users, and when it first appeared. Then it posts a Slack summary of what is new, what is spiking and what it drafted. It leaves the state of every Sentry issue alone, and it never assigns anything to anyone.

How it works

The pattern

An hourly cron opens a session with a read-only connector to Sentry and a tightly scoped GitHub token for drafting. The sorting rules live in skills and memory. The agent skips anything already tracked, drafts issues for the worst errors and posts to Slack, and it never resolves, ignores or assigns an error.

Guardrails

This agent reads live production errors and writes issues other people will act on, so its access is narrow and only flows one way:

• Isolation. Each run happens in a private sandbox. The session may read Sentry and search GitHub, and the only things it sends out are the drafted issue and the Slack message.
• Scoped secrets. The Sentry key is handled by the connector on our servers. The GitHub token is stored encrypted in the Secrets Manager and passed into the sandbox when the run starts. Both are only handed to the agents you grant them to.
• Never resolves, ignores, or mutes. There is simply no way for the agent to change an error's status in Sentry. It reports on the backlog; it does not run it.
• Never assigns. Drafted GitHub issues go out with no assignee. Your team decides priority and ownership.
• Everything is code. The sorting rules, thresholds and per-system permissions are files in the repo, kept in version control. Changing them means a reviewed change request, not a dashboard setting.

The outcome

Sorting errors used to need a spare hour nobody had. Now the backlog shows up already tidied, every hour: new errors and real spikes ranked by impact, checked against what is tracked, and the worst offenders drafted as issues with their trace attached. Your team spends its time choosing what to fix instead of working out what is broken.