Sentry joins production telemetry with AI-assisted debugging

Sentry helps developers understand failures in running applications and connect those failures to the code that caused them. Seer adds AI-assisted diagnosis and repair, while agent tracing observes applications that themselves use AI. The practical decision is where to stop the automatic workflow: an explanation, a proposed solution or a pull request awaiting review.

01 / ProductProduction context gives the debugging agent a starting point

Seer uses issue details, traces, logs, profiles and linked code to investigate application problems. It can propose fixes and support code review. The distinction from a general coding conversation is the starting evidence: a failure already captured by the monitoring system can be connected to the relevant repository and runtime context.

Sentry also offers agent observability. Agent runs, tool calls, model interactions and errors can be inspected together, with conversations available for replay. This observes the application’s AI behavior; it is separate from Seer using AI to investigate a software issue. A team can need one capability without enabling the other.

The Autofix guide organizes work into root-cause analysis, solution identification, code generation and PR iteration. That structure gives a buyer useful control points. A proposed cause can be valuable even when the team is not ready to let an agent write code, and a proposed patch can be reviewed without granting it deployment authority.

02 / AudienceDevelopers with recurring production failures have a concrete use case

Sentry is relevant to application teams whose debugging work begins with exceptions, failed requests or performance problems. A useful pilot starts with issues that already have clear ownership and enough runtime detail to reproduce. The team can then assess whether AI shortens the path from captured failure to a plausible, testable code change.

Teams expecting an agent to repair arbitrary systems without repository context should narrow that expectation. Source mappings, connected repositories, event detail and the relationship between project and service all affect the available evidence. An error message saying that a request failed does not reveal whether the fault lies in code, configuration or an external dependency.

The Datadog blueprint is an adjacent comparison when infrastructure and application-wide observability are the broader requirement. The Augment Code blueprint is relevant when the main need is assistance understanding and modifying a codebase. Sentry’s evaluation should emphasize the connection from production symptom to repair proposal.

03 / WorkflowProposed workflow for a failing AI tool invocation

Imagine an application agent that sometimes fails when it calls an order-status tool. This is a proposed evaluation, not a Sentry test result. The objective is to distinguish invalid tool input, a backend error and a model decision problem, then produce a repair the application team can review against a regression case.

Instrument the agent path so the model call, selected tool, tool arguments and downstream operation can be related where appropriate. Choose what content is safe to capture. The agent-observability guide recommends a sampling strategy that keeps complete agent runs without necessarily sampling every application request. A broken trace can make a successful model call look unrelated to the tool failure that followed.

Select a representative failure and verify the basic evidence manually. Confirm the environment, release and affected request, and identify whether the runtime error is actually associated with the expected repository. If the wrong project points to the wrong code, an AI explanation can become highly specific about an irrelevant implementation.

Connect the intended repository and begin Autofix at the root-cause stage. Ask the reviewer to separate observed facts from inferred causes. For example, a missing argument is observable in a captured request; the claim that a particular prompt change caused it requires comparison with the code and surrounding execution.

Review the proposed solution before generating a patch. A defensive default may prevent an exception while silently changing the meaning of an order lookup. The correct repair may be input validation, a clearer tool schema or an explicit user-visible failure. Define expected behavior for the invalid input before judging whether generated code is acceptable.

If a patch is created, run the relevant regression test and inspect the diff for unrelated changes. Include a valid request, an invalid request and a downstream service failure. A fix that passes the happy path but turns every error into an empty result may hide the original problem from both customers and monitoring.

Keep repository review and deployment approval in the existing engineering workflow. After release, verify that the affected operation behaves correctly and that the failure pattern has changed for the expected reason. A closed issue or a merged pull request is not by itself evidence that customer-facing behavior recovered.

For comparison, ask a developer to investigate a similar issue without Seer, keeping the evidence and issue complexity reasonably comparable. Record time spent validating the explanation, patch changes needed and defects caught during review. Those observations are more useful than counting generated patches, since a patch that takes longer to verify can increase total debugging work.

04 / PricingSeer has a contributor meter separate from telemetry

The billing guide defines an active contributor as someone making at least two pull requests in a month to a Seer-enabled repository. A repository is enabled when connected to Sentry with one or more Seer features turned on. This makes repository scope a commercial decision: enabling a busy shared repository can matter more than the number of people who personally open the AI interface.

The same guide says the old Seer add-on stopped being offered to new subscriptions in January 2026. Do not use older per-run examples to budget a new purchase. It also distinguishes GitHub bot exclusions from GitLab’s account counting, so confirm how your source-control workflow affects the contributor total.

Monitoring has separate reserved volume and pay-as-you-go controls. Once both are exhausted, additional data is dropped. A spending ceiling can therefore create a gap exactly when error volume surges. For the proposed pilot, estimate retained spans and errors separately from Seer contributors, and decide which evidence must remain available during an incident.

05 / DistinctionsThe stopping point can be chosen before code changes begin

The most useful product distinction is that diagnosis and implementation are separable. Autofix can stop after root cause or after a plan, or continue to a drafted pull request according to the configured preference. That gives an engineering team a way to evaluate reasoning first and expand the workflow only after seeing how often it produces the right explanation.

Runtime context can also make a coding task less ambiguous. A developer can inspect the captured failure, relevant code and suggested repair together. This does not guarantee a correct patch, but it gives reviewers more concrete material than a broad instruction to improve reliability. The quality of that material depends on the instrumentation and project-to-repository mapping.

06 / QuestionsRepository hosting and team access impose real boundaries

The Seer documentation supports GitHub.com and GitLab.com cloud integrations for this workflow. A self-hosted source-control installation should not assume equivalent availability. Confirm the specific integration and repositories before treating a product trial as proof that the production codebase can be connected.

Seer Agent, the general conversational investigation interface, is labelled open beta. The documentation says it is unavailable when Open Team Membership is disabled because its queries are organization-wide and it does not yet have finer-grained access controls. That is a meaningful limit for organizations separating teams or projects; it should be resolved before planning broad conversational access.

The Seer controls can prevent Sentry from creating pull requests or pushing code through its own Autofix path. The documentation notes that this setting does not govern separate workflows involving the customer’s own coding agent. Trace authority through every connected tool instead of assuming one toggle constrains all possible implementation paths.

Finally, inspect the types of telemetry and source code included in an investigation. Sentry says it does not train generative models on customer data by default without permission. That commitment is useful, but the team still needs to determine which production records and repositories should be available for debugging and how long that evidence is retained.

07 / DecisionStart with diagnosis that a developer can falsify

Sentry is a prominent AI-related developer platform because it connects production monitoring with AI debugging and provides observability for agent applications. A useful pilot produces an explanation that a developer can test, a bounded proposed repair and a verified application outcome. That is a stronger basis for adoption than a demonstration that merely opens a pull request.