This past week a rare but critical
Sentry alert came through. In the past, once someone saw the alert in Slack, we'd inspect the error, triage it, and start on a fix. Now all of that happens automatically. This time the fix was on production in less than four hours.
This isn't a one-off. That same week, 29 errors were auto-fixed, reviewed, merged, and released, with a median of 8.7 hours from alert to merge.
The larger point: pairing a software robot that constantly monitors error logs with a coding agent creates a much lower threshold for what's worth fixing.
The Backlog Problem
For the uninitiated, Sentry is a service that captures errors from your software along with rich context that makes debugging far easier. It's so much more than that these days, but that's the core of what any developer responsible for production systems happily pays for, and has since David Cramer turned his early open source work into a SaaS offering over a decade ago.
For years, my practice has been to have Sentry alerts pushed to me, first by email and now as Slack notifications. Each one forces a triage decision. Is this critical/urgent, noise, or somewhere in between?
When an issue isn't immediately resolved, it builds up in Sentry's backlog of unresolved issues. That leads to another practice: periodically reviewing the backlog and either closing out issues you don't think will happen again, or logging tickets to get to in the next development sprint.
I don't know about others, but I'm good at closing out issues and bad at ticketing them. Inevitably my unresolved list grows and grows with minor nits. Nothing that dooms a system, just small, ugly cruft that's never worth the opportunity cost of dealing with it now.
With the advent of AI bots, we can now automate mundane, repetitive tasks. Fact is, software robots are better at this than novelty-craving humans.
Meet Sentinel
I have a Grok Bot named Sentinel. Its job is to monitor Sentry and produce PRs to address issues as they crop up. It also picks 2–3 issues from Sentry's unresolved backlog to address each evening, so I have fresh PRs to review each morning. They tend to be quick and easy to review and accept. Lastly, it monitors deployments and resolves any Sentry issues that were addressed in that GitHub release.
Sentinel has instructions to use Claude Opus 5.5, has access to the entire codebase, and spins up the project's Docker Compose stack in its cloud environment. It even captures before/after screenshots of any fix that impacts the user interface. If it has questions about how a fix should go, which is rare but has happened, Sentinel routes the question through my main Grok Bot, which asks me in Slack. I can respond as if I'm responding to a teammate.
Why Not Seer?
Sentry has a built-in product for this purpose called Seer. I tried it in its early days and it didn't take. The folks at Sentry are constantly improving, and a brief glance at the docs looks nice, so it's worth giving Seer another chance. One thing I don't think Seer can do (yet), and that makes reviews much faster, is spin up my entire stack on Cursor's cloud environment and capture those before/after screenshots.
A Human Still Merges
We may eventually auto-merge these, but for now Sentinel can't merge on its own. Every PR gets a review pass from other agents first, then a human review.
The result: the backlog shrinks every night, and I start my morning reviewing fixes instead of triaging alerts. When fixing an error costs a few minutes of review instead of a slot in the next sprint, the cruft stops piling up.