Sentry is one of the best-built tools in its category, and if your agent is wrapped in a real application, you should run it. This is not a teardown. It is a boundary map, because the most expensive mistake teams make with Sentry and agents is not using it wrong, it is assuming it covers more of the agent than it does. Sentry catches everything it was built to catch. Your agent will fail in three ways it was not.
For the wider comparison across the whole platform stack, see beyond Sentry and Datadog; this one stays on Sentry specifically.
What Sentry catches, and catches well
The part of your agent that is ordinary software, Sentry handles cleanly. The function that builds the prompt, the client that calls the provider, the parser that reads the response, the code that writes the result downstream: all of it can throw, and when it does, Sentry is the right tool.
A timeout on the provider call raises an exception, and Sentry catches it with a stack trace and a frequency count. A malformed response that breaks your parser throws, and Sentry groups it, ties it to a release, and tells you which deploy introduced it. A null reference in the post-processing, a rate-limit error you forgot to handle, a crash in the surrounding request: this is Sentry's home ground, and nothing below diminishes it. Keep it.
The point is only this: everything Sentry catches has one property in common. It raises an exception. That is the boundary, and the agent's worst failures live on the other side of it.
Blind spot 1: the answer is wrong, not errored
Your agent calls the model. The provider returns 200. The JSON parses. Your function returns cleanly. And the answer is wrong: a ticket routed to the wrong queue, a summary that missed the point, a fact quietly fabricated.
Sentry sees none of it, because nothing threw. From every signal an error tracker has access to, the request was a success. The thing that broke is the meaning of the output, and meaning is not a category Sentry has. The model did not fail. It succeeded at returning the wrong thing, which is the characteristic agent failure and the one no exception-based tool can see.
Catching it needs a signal that reads the output against a definition of good, which is what quality scoring is. A rubric, a judge, checks on every run and judges on a sample; the score lands next to the run and a drift alert fires when the distribution slides. That is a different instrument than Sentry, watching a different thing.
Blind spot 2: the agent stopped running
A scheduled agent that goes silent produces no exception, because it produced nothing at all. There is no failed request to catch when the request never happened. Sentry is built around things that occur and throw; an event that fails to occur is outside its model entirely.
This is the nastiest blind spot because the absence is invisible by construction. A nightly summariser whose cron entry silently breaks will sit dark for days, and Sentry will show a clean dashboard the whole time, because from its perspective nothing went wrong; nothing went at all.
Catching it needs the inverse of error tracking: a heartbeat per scheduled agent and an expected cadence, so a missed window pages you. That is schedule freshness, and it is structurally a different kind of monitor, one that alerts on absence rather than on events.
Blind spot 3: the cost ran away
An agent stuck in a retry loop, each retry dragging the full conversation history, can quadruple your token bill in a day. Every individual request succeeds. No exception is raised. Sentry stays green while the meter spins.
Cost is simply not a dimension Sentry measures, and reasonably so; it was built to track errors, not money. But runaway spend is one of the most common and most expensive agent failure modes, and it hides perfectly inside a healthy error dashboard. The signal here is per-agent cost attribution with a baseline: the morning an agent's spend pulls away from its own history, you get paged, long before the invoice lands.
The shape of the gap
The three blind spots share one property, the same one that makes Sentry good at its job: none of them throw.
| Failure | Throws? | Sentry sees it? | What does |
|---|---|---|---|
| Provider timeout, parser crash, null ref | Yes | Yes | Sentry |
| Confidently wrong answer | No | No | Quality scoring |
| Scheduled agent goes silent | No | No | Schedule freshness |
| Token cost triples | No | No | Cost attribution |
Sentry is doing exactly what it should. It is just that "did this raise an exception" and "is this agent doing its job" are different questions, and the agent's hardest failures answer the first one with "no" while answering the second one with "also no". The platform layer is healthy throughout; the failure lives in the agent layer, which is a layer Sentry was never pointed at.
Run both, stitch them together
The conclusion is not "drop Sentry". It is "Sentry plus an agent layer", and the two connect cleanly. Propagate a shared identifier: tag your Sentry events with the agent run id and record the same id on the AgentPing run. Now an exception in Sentry links to the full run, with its cost, inputs, outputs, and score, and an alert in AgentPing links back to any related exceptions. Each tool keeps doing the job it is good at, and the shared id lets you pivot between the code view and the agent view on a single incident.
Sentry tells you the code broke. The agent layer tells you the agent broke without the code ever breaking. You want both, because in production you will hit both, and only one of them throws.
If your agents run on Sentry alone, your error dashboard is green and three of your worst failure modes are invisible inside that green. Get started and cover the agent layer on your most important agent first.