A frontend throws a 500. The stack trace points to a React component. The real problem is three services away, in a database connection pool exhausted by a leaking background job.

You could click through trace waterfalls, correlate timestamps, and read commit history. Or you could hand it to Sentry’s Seer, an LLM-powered debugging agent that reads your traces, errors, and code, then tells you what broke.

Seer is good at this. It is not a psychic. The gap between those two statements is what this post is about.

What statistical debugging actually means

Statistical debugging uses patterns across many executions to pinpoint bugs. Traditional debuggers show you one run. Statistical approaches look at distributions: which functions fail together, which traces correlate with errors, which commits preceded a crash spike.

Sentry has done the statistical part for years. Seer adds an LLM to reason about causality on top of that data. It does not replace the statistics. It interprets them.

Seer does not hallucinate root causes from nothing. It looks at the same traces and stack traces you would look at, but it reads thousands of spans in seconds and correlates them with your codebase.

How Seer reads a trace without drowning in spans

A distributed trace can contain thousands of spans. Feeding all of them into an LLM context window is a recipe for confusion. The model fixates on irrelevant details and misses the signal.

Sentry solves this by building a condensed trace tree. Instead of every span, Seer sees a hierarchy of transactions, the service boundaries that group spans into meaningful units. The tree shows which transactions called which others, how long they took, and whether any errors occurred inside them.

Here is what a raw trace looks like conceptually:

GET /api/checkout
├── POST /payment-service/process
│   ├── SELECT * FROM orders
│   └── UPDATE inventory
├── GET /user-service/profile
│   └── SELECT * FROM users WHERE id = ?
└── POST /notification-service/email
    └── SMTP send

Seer receives this tree annotated with timing and error status. It sees the checkout request called three downstream services. It does not see every individual database query unless it asks for them.

The key word is “unless.” Seer has tools. If the tree suggests the payment service is the problem, it can fetch the full spans inside that transaction, connected error events by ID, or CPU profiles. It decides what to look at next.

This agentic approach is the difference between “paste this trace into ChatGPT” and what Seer actually does. A chatbot gets one shot. Seer gets a loop: observe, reason, fetch more data, reason again.

The cross-service problem Seer was built to solve

Before traces, Seer (then called Autofix) relied on stack traces and breadcrumbs. This worked for monoliths. It failed for distributed systems.

Consider a frontend 500 error. The stack trace points to a fetch call. Without traces, Seer would conclude the frontend was broken. With traces, it sees the frontend called the API gateway, which called the auth service, which threw a token validation error because a certificate rotated.

Sentry’s own team hit this internally. An authentication issue between Sentry’s backend and Seer’s microservice had persisted for days. Seer, given the trace tree and access to both repositories, identified the root cause and opened pull requests in both services.

That is the promise. The catch is the setup.

What Seer needs before it can help you

Seer needs three things to work well:

1. Connected traces.

If your services use different Sentry projects with no distributed tracing, Seer sees isolated errors, not a trace tree. You need the Sentry SDK in each service and trace header propagation.

In Python:

import sentry_sdk

sentry_sdk.init(
    dsn="https://your-dsn.ingest.sentry.io/project-id",
    traces_sample_rate=0.1,  # Adjust for your volume
)

For cross-service propagation, the SDK reads and writes sentry-trace and baggage headers automatically on supported HTTP clients. If you roll your own client, attach the headers manually:

from sentry_sdk import continue_trace

headers = {}
continue_trace(headers).apply_to_request(headers)
response = my_custom_http_client.get(
    "http:// downstream-service/api",
    headers=headers,
)

Without this, Seer sees frontend and backend errors as unrelated incidents. The trace tree never forms.

2. Connected code.

Seer searches your codebase to correlate traces with implementation. This requires the GitHub integration and mapping repositories to Sentry projects. Seer cannot read your code from a zip file or local path.

3. Enough signal.

A trace with only auto-instrumented HTTP spans tells Seer that service A called service B. It does not tell Seer what business logic happened in between. Custom spans matter.

from sentry_sdk import start_span

def process_payment(order_id):
    with start_span(op="payment.process", description="Validate and charge"):
        validate_order(order_id)
        charge_customer(order_id)

Without these, Seer sees a black box between the HTTP request and the database query.

The trade-offs nobody puts in the marketing copy

Seer has real limitations, and Sentry is reasonably honest about them.

Accuracy is high, but not 100%.

Sentry reports a 94.5% root cause identification rate. That means roughly one in twenty issues gets misdiagnosed. For high-severity incidents, you still need a human to verify Seer’s conclusion before you deploy a fix.

It costs money per run.

Seer runs cost roughly $1 per root cause analysis, plus a monthly subscription. Automated scans are cheaper at $0.003 per issue. For a team handling dozens of issues daily, this adds up. Configure automation thresholds carefully.

It cannot fix what it cannot see.

If your traces are sampled at 1% and the bug only manifests in the other 99%, Seer will not find it. If the root cause is in a third-party service that does not send traces to Sentry, Seer will hit a wall. If the issue is a logical bug that never throws an error, Seer will never trigger.

LLMs are still bad at some kinds of reasoning.

A Microsoft study confirmed what most developers suspect: AI agents excel at localizing problems but struggle with root cause analysis when the cause is distant from the symptom. Causality across time, especially with race conditions or state corruption, remains hard.

When Seer shines and when to skip it

Seer is worth trying when:

  • You have a distributed system with connected traces across multiple services
  • The issue involves a clear error event that Sentry has captured
  • The root cause is likely in your own code, not a third-party dependency
  • You have enough trace volume that manual investigation is tedious

Skip it when:

  • Your traces are not connected across services
  • The issue is intermittent and rarely captured in traces
  • You need sub-minute resolution for an active incident (Seer takes minutes to run)
  • The root cause is almost certainly infrastructure, not code

How to actually try it

If you are already on a paid Sentry plan, Seer is available as a 14-day trial.

  1. Connect GitHub in your Sentry organization settings
  2. Map your repositories to your Sentry projects in Seer settings
  3. Ensure tracing is enabled in your SDKs with traces_sample_rate set
  4. Open any issue and click Find Root Cause

For automated runs, configure a stopping point. Most teams start with Stop after Root Cause. Once you trust the accuracy, you can let it propose solutions or draft pull requests.

If you use Cursor or Claude Code, you can invoke Seer through Sentry’s MCP server directly in your IDE chat.

The honest bottom line

Seer can find root causes in traces by building condensed trace trees, fetching detailed data on demand, and reasoning across your codebase. For connected, well-instrumented distributed systems, it is genuinely useful. Sentry’s own engineers have saved days of debugging time on cross-service issues.

It is not a replacement for understanding your own system. It is a very fast, very well-read intern who can read traces and code but still occasionally blames the wrong service. Use it to accelerate investigation, not to eliminate it.

If your traces are clean, connected, and full of useful spans, Seer will probably impress you. If they are not, fix the traces first. No LLM can debug what you never bothered to instrument.

FAQ

Does Seer work with self-hosted Sentry? No. Seer is a cloud service that requires sentry.io. It relies on Sentry’s own infrastructure to run the LLM agent and access your telemetry. Self-hosted instances do not have access to Seer.

Can Seer analyze traces from languages other than Python and JavaScript? Yes. Seer reads trace data from Sentry, not raw language-specific telemetry. Any service instrumented with a Sentry SDK that produces traces can feed into Seer. The code analysis step requires GitHub integration, which works with any language.

What happens if Seer gets the root cause wrong? You can provide feedback during the analysis, and Seer will incorporate it. The final output always requires human approval before any code changes are applied or PRs are opened. Nothing ships automatically unless you explicitly configure it to.

How is this different from just pasting a stack trace into Claude or ChatGPT? A chatbot gets a single context window with whatever you paste. Seer gets an agentic loop with access to your full trace tree, connected errors, CPU profiles, and codebase. It can fetch more data as it reasons, and it knows your system’s structure because it reads the actual code.