Start with the errors affecting your product
The error triage agent reads Sentry and the repository together. It looks at unresolved issues in the review window, focusing on newly seen problems, rising event counts and issues affecting the most users. It separates likely bugs in your code from browser extensions, bots, network interruptions, third-party scripts and old application versions. Each classification needs a reason: an unfamiliar stack trace alone does not prove that the current release is broken.
For a likely bug, the agent follows the stack trace into the checked-out code, examines the surrounding behavior and proposes the smallest plausible fix. Releases, tags and breadcrumbs can help connect an error to a particular path or change. When the evidence is incomplete, the result should say what is missing rather than inventing a root cause. A report can be valuable because it narrows the next investigation, even when no code change is ready.
The scheduled workflow produces a report and ranked findings. Its instructions cap the proposed actions at eight and prioritize severity and affected users against effort. A purchase failure, lost data or blocked sign-up deserves different attention from a noisy cosmetic error. Noise that consumes the error quota may also justify an action, such as proposing a change to the application's Sentry filtering configuration for a person to consider.
Illustrative example: a checkout callback error
This example explains the workflow. It is not a customer result or a claim that InfraStudio Agents has completed this particular Sentry investigation. Imagine a checkout callback raising an exception when a return URL lacks an expected parameter. Sentry groups matching events into an issue; the agent checks whether the events share a release and code path, and whether the stack originates in the application rather than an extension.
The report would distinguish observation from inference. Observation: the stack points to a lookup that assumes a parameter exists. Possible cause: a supported callback path can omit that parameter. The code investigation must establish whether the payment provider contract permits that path, whether the return handler validates it elsewhere, and whether the current checkout state supplies another safe source. Without those checks, adding a fallback could hide a more serious state problem.
A finding could propose handling the missing parameter explicitly and showing a recoverable message, with tests for both a normal return and an incomplete callback. The plan would name the affected handler, explain the expected user behavior and identify verification steps. A workspace admin or owner could request a plan, ask for changes, reject the finding or approve implementation. Only after that decision would the implementation workflow prepare a pull request.
The PR would need review and CI before a human decides to merge. After release, compare the same Sentry issue and relevant release window, allowing for traffic and reporting delay. Fewer events do not by themselves prove that the fix improved checkout conversion. There are no invented event counts, customers, recovered revenue or success percentages in this example.
What reaches the team
The report includes a summary, an issue table and a section for each proposed bug fix. The useful chain is the issue, its evidence in the selected window, the relevant stack frame, the proposed code change and how to check the outcome. Findings keep the work connected to the report and the decisions that follow. Existing open actions should retain their identity instead of becoming a fresh duplicate at each scheduled review.
Triage itself is read-only. It does not resolve or assign issues in Sentry and it does not change the code during the review. Code implementation is a later, approved action. That separation lets someone reject a speculative diagnosis without cleaning up a surprise commit. The PR reviewer then examines the implementation, while the CI fixer can investigate failing checks.
Connect Sentry and choose when it runs
- Use a workspace admin or owner account to add or choose the project and configure its integrations. Connect the intended Sentry project with the access the read-only integration requires.
- Review event triggers before adding the AI key. New GitHub projects have their runner and five event agents enabled. If a workspace key already exists, consider that behavior before connecting the repository.
- On Agents, open Settings on the project card. Error triage is a separate scheduled workflow, off by default, with a morning schedule available when enabled. Choose its model and review its limits.
- Run error triage manually first as an admin or owner. Inspect the report against Sentry and the code, then decide whether to enable its schedule. A manually added GitLab project also needs its runner enabled.
Keep the integration and repository scopes aligned with the project you intend to investigate. Read the security overview for how the platform handles keys and removes personal details from integration responses. Your AI provider still processes the material sent to it under the provider policy for your account. Use the plan limits and actual provider usage when deciding how often to run a large investigation.
When Sentry Seer may be the better fit
Sentry's first-party Seer issue-fix documentation describes root-cause analysis, solution and code stages, pull request creation, and coding-agent handoff. Seer is therefore more than error summarization. If your team wants issue investigation centered inside Sentry, evaluate that workflow directly against the Sentry projects and repositories you use.
InfraStudio Agents approaches the job through the same project findings and approval loop used for analytics reviews and other repository work. Its potential fit is a team that wants Sentry evidence beside GA4, PostHog or Clarity findings, with its own AI key and chosen models. This is a workflow distinction, not a claim that one system always diagnoses more accurately or that Seer lacks implementation features.
Automation depends on the data available. Missing source context, absent release information, incomplete breadcrumbs and an issue that cannot be reproduced can all limit a diagnosis. A report is a proposal for engineering judgment. Read the full analytics-to-pull-request loop for how approval and verification fit together, and our real billing-webhook case for repository evidence from our own product rather than an illustrative Sentry result.