Rollbar Resolve

AI-assisted ability to root cause and fix an error in Rollbar.

Resolve is an AI agent in Rollbar that takes a production error and produces a pull request you can review.

It works in two stages. First, root cause analysis investigates the error across the projects and services you use to surface where the failure started, not only where it appeared. Then Resolve takes that analysis, writes a code change in an isolated environment, runs your project's tests and checks against it, and opens a pull request.

Both stages live on the Root cause & fix tab of any item. You can stop after the analysis if all you need is an explanation, or continue to a fix.

Resolve and root cause analysis are triggered manually. Neither runs automatically. If you would like to opt out of AI features entirely, contact [email protected].

📘

Resolve is in open beta.

Resolve is in open public beta. Any account on any plan can use it, as long as you have a credit subscription and the GitHub App installed.


Requirements

  • A Rollbar account with an active credit subscription and available credits. Available on all plans, including Free. See Credit Billing.
  • The New Rollbar GitHub App installed, with the relevant repository mapped to your project.
  • Optional, for cross-project analysis: Rollbar JS SDK v3.1.x or Python Rollbar SDK v1.4.x or higher.

Root cause analysis needs read access to your code. Resolve needs write access, because it creates a branch and opens a pull request. Both come from the same GitHub App installation.


How Resolve works

When you launch a fix, Rollbar's Resolve runs through the following steps.

  1. Correlate. Resolve finds related occurrences across the projects you can access, using propagation IDs and session correlation so errors from the same request or user session are treated as one failure rather than separate items.
  2. Load context. An isolated sandbox is created. Resolve clones your mapped repository into it at the commit associated with the occurrence when that information is available, and loads the item, its occurrences, and related telemetry.
  3. Analyze. The agent works out the probable root cause and writes it up.
  4. Change the code. Resolve makes a change in the sandbox.
  5. Verify. Resolve runs the tools you have configured, such as your test suite and linters.
  6. Open a pull request. Resolve pushes a branch and opens a PR against your repository.

The verification step in the middle is the point. Resolve is not trying to guess at a patch and hand it over. It runs your own checks against its change first, so what reaches your review has already been tested the way your team tests code.

You stay in control of the merge. Resolve never merges its own work.


Setting up GitHub

Resolve uses the Rollbar GitHub App. If you previously connected GitHub through OAuth for code context, installing the app replaces that connection.

Installing the app

  1. Go to Account Settings → Source Control.
  2. Choose Connect GitHub.
  3. Select the repositories you want Rollbar to access. You can choose specific repositories rather than granting access to all of them.
  4. Map the relevant repository to your Rollbar project.

The settings page shows which repositories are connected, the primary language of each, and who installed the app.

For full setup steps, see GitHub Integration.

Running root cause analysis

You can start an analysis from any item.

  1. Open an item in Rollbar.
  2. Open the Root cause & fix tab, or choose Analyze root cause in the action bar at the top of the page.
  3. Choose Analyze root cause.

While the analysis runs, the tab shows a live progress stream that scrolls to the newest line. If you scroll up to read earlier messages, auto-scroll pauses until you choose Resume auto-scroll.

You do not need to keep the page open. The analysis continues in the background, so you can look at other items or leave Rollbar and come back for the result.

Reading the analysis

When the analysis finishes, the tab presents three sections.

Context frames the error: what is failing in production, how it appears in Rollbar, and the signals you need to orient yourself, such as affected services, payloads, messages, and stack traces. It answers what happened before explaining why.

Root cause explains why the error occurs: the error path, proximate versus systemic causes, where it happens in your code when a repository is mapped, and any unknowns the data could not settle. Subheadings vary by error, so read the body under each heading rather than only the titles. Correlated item IDs may appear inline.

Probable solution is the recommended direction for a fix. It is guidance, not a guaranteed patch.

Impact and reproduction notes may appear under either Context or Root cause depending on the run.

When the root cause cannot be determined

If the model cannot determine a root cause confidently, the tab shows Root cause indeterminable with a short explanation.

This usually means the analysis had no usable view of your code. The most common causes are GitHub not being connected, the repository not being mapped to the project, or source maps for client-side code being missing or uploaded incorrectly, so stack traces never resolve to real files. Fixing source integration is normally the highest-leverage change. Once setup is corrected, choose Retry analysis.


Launching a fix

When an analysis has finished, choose Fix this error to start a Resolve run.

Before the run starts, Rollbar checks that GitHub is connected, that the repository mapping is valid, and that you have enough credits. If something is missing, you are prompted to fix it without leaving the page.

If the item is not already assigned to someone, launching a fix assigns it to you.

Following the run

While Resolve works, the item shows an indicator that a Resolve task is in progress, so anyone else looking at the item knows work is underway. The Root cause & fix tab streams the run log live, so you can watch what Resolve is doing step by step: which files it read, what it changed, and how your checks responded.

A Resolve task is always in one of four states:

StatusMeaning
In ProgressResolve is working.
BlockedResolve cannot continue. The tab explains why.
CompletedResolve finished and opened a pull request.
CanceledThe run was stopped.

To stop a run, choose Cancel. Cancelling is final for that run. There is no pause and resume in this release, so a cancelled run has to be started again from the beginning. Resolve will not cancel in the middle of a run so when the cancel button is pressed, Resolve will finish its task and not move any further. Any tokens consumed after a cancel button is pressed will still be charged.

You can also see which items have agent activity from the Items list. Items that have been through RCA or Resolve show a sparkle icon, and selecting it opens that item's Root cause & fix tab. To see only those items, open the filter panel and choose Agent Involved.


Reviewing the pull request

When Resolve finishes, it opens a pull request against your repository and links it from the item. The item timeline records that the PR was created.

The pull request description explains what Resolve changed and why, and links back to the Rollbar item so anyone reviewing it can see the original error. Commit messages include a reference back to the Rollbar item.

Review a Resolve pull request the way you would review a teammate's. It has passed the checks you configured, but you decide whether the change is right.

Note: Resolve creates its commits without running local Git hooks, because the sandbox does not have your project's hook tooling installed. Your repository's own CI still runs against the pull request as normal.

When the pull request merges

When you merge a Resolve pull request, Rollbar records the merge on the item timeline and marks the involved items as resolved.

If a run finished but you would rather close out the items yourself, choose Resolve involved items manually.


One fix, several items

Errors often show up in more than one place. When the analysis determines that several items share a root cause, the Resolve task and its pull request are attached to all of the affected items, and each one shows the same status.

This also covers the cross-project case, where the item you started from is a symptom and the root cause sits in a different project. The task and PR attach to both, so you can see what will be fixed together instead of opening duplicate work.

Currently during beta, Resolve will only fix an item in the current project for a single repository. If you have multiple projects and your error is caused by an item in another project, trigger Resolve on the related items project to get the correct fix.


Cross-project analysis

Rollbar ties occurrences together using propagation IDs in SDK payloads. This is how an analysis that starts on a frontend item can point to a backend service as the real source.

Rollbar SDKs attach a session ID that travels in an HTTP baggage header between services. When both the calling service and the downstream service report to Rollbar, their errors share that identifier, and Rollbar uses it to find related occurrences across projects, services, and timestamps within the same session.

Cross-project correlation is currently supported for JavaScript and Python:

If analyses rarely link upstream and downstream items, upgrading these SDKs is usually the fastest improvement you can make.


Permissions and access

Roles

RoleCan do
OwnerStart and cancel runs, view results, manage tools and secrets, view credit balance and usage, adjust per-run limits
StandardStart and cancel runs, view results
LightStart and cancel runs, view results
View-onlyView results only. Cannot start a run.

Project access

Resolve and root cause analysis follow your existing Rollbar project permissions. A run only uses projects your account can access.

  • If you have access to every project on the error path, you see the full result.
  • If you are missing access to one or more of them, a banner explains that the analysis uses data from projects you cannot see. Ask your account owner for access.
  • If the analysis was started by someone with broader access than you have, you may see an access restriction instead of the results.

Someone with access to all participating projects can re-run the analysis for a complete result. Restricted users continue to see only what their permissions allow.


Limitations and blocked states

Single repository only

Resolve Beta can only change one repository per fix. If the analysis determines that a fix requires changes across several repositories, Resolve cannot be launched for it, and the tab explains why. This is the most common reason a fix is unavailable on an item that has an otherwise good analysis.

GitHub not connected

If GitHub is not connected for the project, the tab shows Not Connected and a path to authorize. Neither analysis nor fixes can run until GitHub is connected and a repository is mapped.

A related project without GitHub

If the analysis finds related occurrences in a project that does not have GitHub connected, that project appears in a blocked state. You can connect GitHub for it without leaving the tab, or continue without it, in which case the run proceeds with the connected projects only and notes the missing code context.

Invalid repository mapping

If stack frames do not map to real paths in the mapped repository, Rollbar blocks the task and tells you how to correct the mapping rather than producing a low-quality result.

Credit limit reached

If a run reaches the per-run credit limit, it stops before finishing. An account owner needs to raise the limit under Account Settings → Agent Settings, after which the run can be started again.


Credits and pricing

Resolve and root cause analysis both spend credits from your account balance. Credits are a monthly add-on subscription, available on every plan including Free. See How to add a credit subscription.

When a run starts, Rollbar reserves your per-run limit against your balance for the duration of that run. The default limit is 12,000 credits, and is configurable by account owners under Account Settings → Agents.

Two things follow from that reservation:

  • There is a minimum balance of your per-run-limit required to start a run. If your balance is below it, the run will not start and you need to add credits or enable on-demand.
  • Reservations limit how many runs your team can have going at once. If concurrent runs reserve the whole balance, further runs wait until the current ones finish.

A Resolve run costs more than an analysis on its own, because it includes writing code and running your checks in a sandbox in addition to the analysis.

If your balance runs out mid-run, Rollbar completes the run that is already in flight. With on-demand enabled, the extra usage is billed as an on-demand overage; without it, your balance may go negative. To cap monthly spend, set a Credit Budget under Account Settings → Billing Info.

Your credit balance resets at the start of each billing cycle and unused credits do not roll over.

Each run records who started it, when it ran, and how many credits it used. The Root cause & fix tab shows your balance and per-run limit while you work, and the Usage Breakdown tab shows history by task type.

Learn more in Credit Billing.


Data processed by Resolve

When you run an analysis or a fix, Rollbar processes your error data using two external providers: a compute sandbox and an LLM agent.

With GitHub connected

The sandbox receives:

  • The item snapshot, a structured JSON file containing the error title, status, severity, environment, framework, occurrence body (stack trace, request data, custom context), recent comments, status history, and occurrence trends.
  • Your source code, cloned at the commit associated with the occurrence when available.
  • Your configured secrets, so your tests and checks can run.

The LLM agent receives the full contents of the item snapshot and the source files it reads during the session.

Without GitHub connected

Both the sandbox and the LLM agent receive the item snapshot only.

What neither provider receives

  • metadata fields from the raw occurrence body, which are stripped before the snapshot is built.
  • body.telemetry, which is excluded from the parameter summary.

Writes back to your repository

Resolve creates a branch, pushes commits, and opens a pull request in the repositories you selected during installation. It does not merge pull requests and does not push to your default branch.


AI privacy and data retention

Your data is not used to train or improve models. Data used for analysis and fixes is not retained by the LLM agent. Rollbar operates a Zero Data Retention (ZDR) policy with its AI sub-processors.

Resolve and RCA data follows the same retention policy as Items and Session Replays, configured in your account settings. When that window elapses, Rollbar keeps the run record, its metadata, and the associated item, and removes the analysis content, responses, and feedback.


Models

Root cause analysis is run on GPT 5.4 Codex and Resolve currently use GPT 5.6 Codex. The model is subject to change without notice.


Did this page help you?