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.
Sentry's AI agent monitoring, briefly
If you searched for "Sentry agent" you may be after Sentry's own product rather than this argument, so here it is first. Sentry now ships agent monitoring as part of its tracing product. Checked against Sentry's docs in October 2026:
- What you get. An Agents area with three views: Conversations (multi-turn exchanges grouped by conversation id), Traces (an agent run end to end, with each model call, tool call and downstream service), and LLM Calls (individual model requests with token usage, cost and latency). The dashboards roll up agent executions, model cost, token usage, tool calls and recent errors.
- Where it runs. Setup guides cover Python, Node.js and several JavaScript runtimes including Next.js, Cloudflare and Mastra, plus Laravel, Ruby and .NET. The Python and Node SDKs auto-instrument the common libraries (OpenAI, Anthropic, LangChain and LangGraph among them), and you can instrument anything else manually.
- The catch worth knowing. It is built on tracing, so an agent run only appears if its trace is sampled. Sentry's own guidance is to sample AI traces at 100%, which is sensible and also something to price before you turn it on across every agent.
If you already run Sentry, turn it on. Seeing model calls and tool calls inside the same trace as your exceptions is genuinely useful. What follows is about the failures that still sit outside it, because agent tracing tells you what a run did, not whether it was right, whether it ran at all, or who it was for.
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, and neither error tracking nor agent tracing has anything to show for a run that did not start.
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 with a clean error dashboard the whole time, because nothing went wrong; nothing went at all.
To be fair to Sentry, it has a separate product for this: Crons, which monitors scheduled jobs through check-ins and alerts when a job fails, runs over time or does not check in. If your agent runs on a plain cron and you already pay for Sentry, wire it up. The limit is that it watches the job, not the agent: it knows the schedule fired, not what the run cost or whether its output was any good, and agents triggered from n8n, queues or another agent rarely look like a cron entry.
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, and nobody knows whose it was
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. The error dashboard stays green while the meter spins.
Sentry's agent tracing now shows token usage and model cost on the calls it traces, which is a real improvement and enough to see that a run was expensive. What it is not built around is spend as an operational signal: attributing cost to the customer and feature a run served, and paging you when one agent's spend pulls away from its own history. Runaway spend is one of the most common and most expensive agent failure modes, and seeing a cost column after the fact is not the same as being woken up by it. 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 | Only with Crons check-ins wired up | Schedule freshness |
| Token cost triples | No | Visible per traced call, not attributed or baselined | 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 Agent Ping run. Now an exception in Sentry links to the full run, with its cost, inputs, outputs, and score, and an alert in Agent Ping 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.