# Rollbar vs Raygun: Hands-On Error Tracking Comparison for 2026

My test bookstore shipped a release in which every fifth card payment failed with a `PaymentGatewayError`. It was a single bug thrown from a single line of code, yet Rollbar filed it as two items and Raygun filed it as two groups.

The two tools split it for different reasons. Rollbar saw the stack trace under my code change shape from one request to the next, and Raygun saw the amount change inside the message, "44 USD" in one group and "35.5 USD" in the other. **Rollbar groups on the stack and Raygun groups on the message**, and you'll want to know which habit you're dealing with before you trust either tool's error count after a deploy.

The products are built differently too. Rollbar is a focused error tracker with session replay built in and a strong habit of linking errors to the deploys that caused them. Raygun sells three separate products, Crash Reporting, Real User Monitoring and APM, which between them cover more ground and share very little with one another.

[ad-logs]

Rollbar and Raygun both watched one Node.js bookstore of mine, where I planted identical browser and server failures and pushed three releases past each tool. The last release was a bad deploy that made checkout more than a thousand times slower, and neither tool noticed.

Every screenshot below comes from that test in October 2026. Below, you can compare them area by area: setup, capturing errors, debugging, grouping, session replay and real user monitoring, release tracking, performance, logs, alerting, AI features and pricing.

## Rollbar vs Raygun: Results at a glance

The verdicts below reflect my Node.js and Express setup, so a different stack or configuration could change some of them.

| Area | Better in my test | Why |
|---|---|---|
| Setup | **Rollbar** | One project took both SDKs; Raygun needed two applications and a load-order fix |
| Error capture | **Rollbar** | Caught the unhandled promise rejection that Raygun missed |
| Debugging | Mixed | Raygun scopes server breadcrumbs to one request; Rollbar rebuilds the failing request as a curl command |
| Error grouping | **Neither** | Both split the new payment error, Rollbar by stack and Raygun by message |
| Session replay | **Rollbar** | Video replay on the error page; Raygun records session timelines only |
| Real user monitoring | **Raygun** | Page and request timing plus Core Web Vitals; Rollbar has no RUM |
| Release tracking | **Rollbar** | A suspected deploy on reopened and new errors, and deploys by API on the trial |
| Performance monitoring | **Raygun**, with caveats | RUM found slow pages and requests; neither tool saw the checkout slowdown |
| Logs and events | Neither | No log product in either; Rollbar's RQL only queries error occurrences |
| Uptime, status pages and alerts | Not compared | No uptime or status pages found in either; alert delivery not tested |
| AI-assisted debugging | Not compared | I ran neither tool's AI |
| Starting price | **Rollbar** | A free plan and paid plans from $9 a month; Raygun starts at $40 a month per product |

## How I tested Rollbar and Raygun

The test app is `monitoring-lab`, a bookstore I built to fail in known ways. A Vite storefront talks to an Express 5 API on SQLite, alongside a mock price service that misbehaves on cue and a sales report job that errors every minute.

Each side of the app loads one small adapter file per monitoring tool, so Rollbar and Raygun received the same failures from the same code.

The planted problems fell into five groups:

- **Server crashes:** a `TypeError` when checkout gets an unknown coupon, and another when a book is missing.
- **Other server failures:** a handled out-of-stock error, a 503 from the price service, a promise rejection nobody catches and the failing report job.
- **Browser failures:** a crash on the wishlist button, plus requests from the storefront that fail with 404, 500 and 502 responses.
- **Performance problems:** a cover image that never loads, a price lookup and a book page that are both slow, and a search that hogs the CPU.
- **Release problems:** a resolved bug shipped unfixed, and a bad deploy with a slow query and a brand-new payment error.

A traffic script sent three shoppers, alice, bob and carol, through the store over the API and in headless Chromium.

### The three releases

I shipped the same three versions to both tools.

| Release | What I tested |
|---|---|
| 1.0.0 | Setup, browser and server capture, source maps, breadcrumbs, user context, replay and RUM |
| 1.1.0 | The coupon crash marked as fixed for this version, then shipped with the bug still in place |
| 1.2.0 | A bad deploy: one checkout query stalls, and one card charge in five fails with a new error |

Release 1.2.0 carried most of the weight. It produced a new exception that any error tracker should catch, and a slowdown that throws no exception at all, so it tested whether each tool could see trouble that never crashes.

### SDKs and test limitations

Both tools ran in the browser and on the server for all three releases.

| Platform | SDKs |
|---|---|
| Rollbar | `rollbar` on the server, `rollbar/replay` from rollbar 4.1.0 in the browser |
| Raygun | `raygun` 2.2.10 on the server, `raygun4js` 3.1.4 in the browser |
| Raygun APM | `raygun-apm` 2.3.0 with the Raygun APM Agent, release 1.0.0 only |

Keep these conditions in mind when you read the results:

- **Both tools ran on trials.** Raygun's trial blocks Personal Access Tokens, so source maps and deployments went in by hand.
- **Traffic ran separately for each tool.** Both saw the same scenarios, but their event counts aren't comparable one to one.
- **The storefront reports "production" and the API reports "development".** That's how my build is set up, and it splits any setting that works per environment.
- **Raygun APM ran only in release 1.0.0.** I uninstalled it before 1.1.0 and 1.2.0 because it broke Crash Reporting, which I cover in the performance section.
- **Only Node.js was tested.** Grouping rules and APM coverage vary between language SDKs.
- **Some features weren't tested.** I didn't run either tool's AI, and I didn't test alert delivery.

## Setup and onboarding

Setup decides how much of your app ends up in one place. Rollbar took the browser and the server in a single project, while Raygun wanted a separate application for each.

### Rollbar: One project, after a token detour

Rollbar's Node.js page, "Add the Rollbar SDK to your application", is four short steps with an estimated time of 5 minutes. You install the package, put the token and environment in `.env`, create the client with `captureUncaught` and `captureUnhandledRejections`, and add `rollbar.errorHandler()` as the last middleware.

The SDK picker shows one SDK at a time:

![Rollbar onboarding SDK picker](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/dc3fca62-38e9-4ae2-4f4c-adaf6da04500/lg2x =1126x736)

You pick Node.js here, then come back through "Select different SDK" for the browser snippet, even though the same project accepts both.

My fresh project still stumbled. Its setup pages printed tokens from an older project I had deleted, and the new project's "Project access tokens" page listed no tokens at all, so nothing I sent was accepted.

The fix was to add a `post_server_item` token and a `post_client_item` token by hand under Project settings. Saved item filters also pointed at the deleted project and read "Projects no longer available" until I picked the project again.

Two smaller things are worth knowing. The Replays setup page suggests `npm install rollbar@3.0.0-rc.1`, which is older than the 4.1.0 I used, and the onboarding sets the user with `rollbar.configure` on the whole client, which concurrent requests can overwrite. My adapter attached the user per request through `req.rollbar_person` instead.

### Raygun: Two applications and a browser that wouldn't start

Raygun builds everything around applications, each with its own API key and its own error list. I made one for the API and one for the storefront.

Onboarding starts by asking for the first application:

![Raygun onboarding, step 1, creating the first application](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/8738305f-d055-4bfa-d3b1-cd4f7c1dc800/public =3024x2044)

The page explains that applications let you monitor each part of a system separately, and the banner shows "Trial active: Day 1/14".

Raygun also sets up one product at a time: "We currently only support setting up one product at a time for your selected language." The last step waits for data from each product before it lets you go:

![Raygun onboarding step 3 with Real User Monitoring still waiting](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/3a9a6759-70d2-455d-674a-2241b56b5100/public =2244x1388)

Crash Reporting has its green check, while Real User Monitoring still has nothing. To move past this screen, I used `curl` to post an invalid coupon to the API.

The browser library needed more work. `raygun4js` reads its configuration at the page's load event, and my storefront imports its monitoring module after that event has fired, so the library never started and sent nothing.

I copied the approach from Raygun's CDN snippet, queuing calls first and importing the library after the page loaded, and data began to arrive. The npm instructions don't warn about this.

### Setup comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| Browser and server in one place | ✔: one project | ✘: one application each |
| API keys | Separate server and client tokens in one project | One key per application |
| SDK picker | One SDK at a time | One product at a time |
| Onboarding blocker | Stale tokens from a deleted project | Waits for data from every product |
| Browser setup | Worked once tokens existed | Needed a load-order workaround in my app |

**Verdict: Rollbar.** Once I created working tokens, one project covered the whole app. Raygun needed two applications and a workaround before the storefront sent anything.

## Error capture

Both tools received errors from the browser and the server. The gap was one promise rejection that nothing in my app caught.

### Rollbar: Every planted error, in one list

After the first release, Rollbar's items list held all 11 items from both sides:

![Rollbar items list with browser and server items](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/95cf05e5-7da0-4bce-cafa-4b0656f90b00/md1x =1126x736)

Six server items sit beside five browser items, and the browser rows carry a replay icon. Failures the storefront caught and reported on purpose, such as the checkout request that came back with a 500, appear too, because the browser SDK can send handled errors.

The unhandled rejection, "Recommendation engine timed out", arrived as item #3. In one of my runs it came in at the "debug" level:

![Rollbar promise rejection with one frame at debug level](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/0e416fad-85cd-4b42-be9f-49f3bf261800/md2x =1126x737)

It has a single frame, `loadRecommendations server.js:144:8`, no request and no user, and only an `is_uncaught: true` attribute in its params says it crashed. Check the level before you filter the list by severity.

Rollbar doesn't badge handled and unhandled errors either. The handled out-of-stock error showed "error", the same level as the crashes.

### Raygun: Five server groups, one rejection missing

Raygun's API application opens on a dashboard that defaults to a 7-day range:

![Raygun Crash Reporting dashboard for the API](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/4bff9e4d-3138-4dac-83aa-a351a8d07f00/lg2x =1512x744)

On a new app, the errors-by-hour chart covers a week of nothing, so it shows a flat line and a single spike at the right edge, and you'll want a shorter range.

The error groups list held five server errors:

![Raygun API error groups](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/80ea8849-b421-413a-a3cc-d0e77e033b00/lg2x =1512x744)

The sales report, the 503, the out-of-stock error and both crash `TypeError`s are there. "Recommendation engine timed out" is missing, even with `reportUncaughtExceptions` switched on.

That's what happened in my setup, and it doesn't prove Raygun misses every rejection in Node.js.

The storefront errors sat in the second application, with 8 groups and tags such as UnhandledException and UnhandledPromiseRejection.

### Error capture comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| Browser crashes | ✔: captured | ✔: captured |
| Server crashes | ✔: captured | ✔: captured |
| Handled errors | ✔: captured | ✔: captured |
| Unhandled promise rejection | ✔: captured, once at debug level | ✘: missed in my setup |
| Handled or unhandled badge | ✘: level only | ✔: tags on browser errors |
| One list for both sides | ✔: yes | ✘: separate applications |

**Verdict: Rollbar.** Every error I planted, browser or server, showed up in a single list. Raygun missed the rejection in my test, and its two applications mean two lists to watch.

## Debugging an error

A caught error is only useful if it tells you where to look. I compared source maps, user and request context, breadcrumbs and the link between a browser failure and its server cause.

### Rollbar: Source maps by script and a request you can replay

Rollbar can't fetch source maps from localhost, so I uploaded them with a script using the project token. The wishlist crash then pointed at my real source:

![Rollbar browser error with source maps and the replay panel](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/66342d0d-affd-454f-fc9a-da0ca3ba7600/lg2x =1126x736)

`bookDetail(../../src/pages.js:122:13)` is highlighted on `wishlist.items.push(book.id);`, and the "Session replay & telemetry" panel sits underneath on the same page.

Server frames are thinner. Rollbar shows one project frame, such as `server.js:81:44`, collapses the rest as "9 non-project frames", lists anonymous handlers as `<unknown>` and shows no source lines.

The params view makes up some of the ground. It's a flat list of keys with a Typicality column that shows how common each value is across occurrences:

![Rollbar handled error with custom data and typicality](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/66995cc8-765a-4518-bc68-9ec16101b900/md1x =1126x737)

On this handled error, `bookId` sits at 74% typicality, so you can see at a glance that most occurrences involve the same book.

Rollbar's server telemetry covers the whole process, and that hurts when several shoppers are active:

![Rollbar telemetry mixing different requests](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/f0856e3b-852d-4ed4-1eed-c95de72b5400/lg2x =1126x737)

Bob's checkout crash lists carol's and alice's orders and other price lookups in the same 100-event timeline. On a later payment error for alice, her name appeared 8 times, bob's 6 times and carol's 5, and the timeline also kept raw ANSI colour codes from my console output.

Rollbar offers something Raygun doesn't. You get the failing request turned into a runnable command:

![Rollbar Replay CURL command](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/4bc5f872-814b-4673-9649-5b619338cf00/lg1x =1126x737)

Paste it into a terminal and you resend bob's failed checkout, with its headers, body and coupon, against your own server.

### Raygun: Manual source maps and breadcrumbs that stay in their request

Before source maps, Raygun's storefront errors pointed into the bundle:

![Raygun browser error with a minified stack trace](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/4754304c-a73a-4e80-154a-ecac4d799200/orig =1512x744)

`index-tWfydWxy.js:2:2762` won't help you find the wishlist bug.

Raygun's upload API needs a Personal Access Token, and the trial answers "Purchase a plan to use this feature." Every map went in through the JS Source Map Center instead, and every upload arrives unlabelled:

![Raygun source map uploads waiting for URL labels](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/a3506607-4462-44fe-b1b4-fc90d5033c00/lg2x =2534x1482)

All four rows read "Please enter resource URL here", so you type the absolute URL of each file yourself. File names change on every build, so you repeat the job after each one.

The labelled center pairs each file with the URL the browser loads it from:

![Raygun JS Source Map Center with labelled files](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/9076a618-750e-41ea-255f-80fc46f96300/md2x =1512x800)

Labels got swapped between files twice during my test, and an edit only saved when no other row already held that URL.

Once the labels were right, "Re-process this error for Source Maps" fixed the error straight away:

![Raygun browser error with the source-mapped stack trace](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/d73c0be4-130e-486c-fe1e-426647522c00/lg2x =1512x744)

The frame now reads `../../src/pages.js:122`, column 13, with lines 119 to 125 and my deliberate-bug comment in view. That matches what Rollbar showed.

Server frames carry no code in Raygun either:

![Raygun server stack trace without source lines](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/5830670b-f9fe-4873-32ea-dfd420bc7200/md1x =1512x744)

You get `server.js:150` and "1 framework frame", with no surrounding lines.

The error page header puts the counts first:

![Raygun API error page header](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/50546a16-8dfe-4769-eecd-fabb8545a600/lg1x =1512x744)

Above the HTTP, Environment, Custom, Breadcrumbs and Raw data tabs, you see total instances, first and last seen, and affected users with a link to the Customers page. "Browser affected: curl 8.7.1" came from the test request I sent during onboarding.

In the browser, Raygun records breadcrumbs without any setup:

![Raygun browser breadcrumbs before an error](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/5896e7d7-b250-4670-d855-e012afe83d00/md2x =1512x744)

Clicks, hash changes, "Navigated back" and each request opening and finishing appear in order, next to my app's own breadcrumbs.

On the server, Raygun keeps breadcrumbs inside the request that failed:

![Raygun server breadcrumbs for one checkout](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/48e74d37-6f47-4325-f552-8f3ace56b700/lg1x =1512x744)

POST /checkout, "checkout started" and "book found" are all you see, with nothing from the other shoppers. Compare that with Rollbar's mixed timeline above.

### Linking the browser to the server

When the storefront's checkout request fails, it raises a browser error, and the server records the crash behind it. Neither tool joins the two.

Rollbar keeps them as separate items, #8 and #2, and its Related tab doesn't help:

![Rollbar Related tab listing similar titles](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/145e2290-e0c0-479b-f1fd-0a038495ff00/md1x =1126x736)

The tab reads "Similar items, based on item titles", so it lists other browser `ApiError`s and nothing from the server. It's also a paid feature after the trial.

Raygun keeps the two errors in different applications. Neither tool has distributed tracing to carry the link across.

### Debugging comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| Browser source maps | ✔: script upload with project token | ✔: manual upload on the trial |
| Re-labelling after each build | ✘: not needed | ✔: required |
| Server source lines | ✘: frames only | ✘: frames only |
| Server breadcrumbs | Process-wide, mixes shoppers | ✔: scoped to the request |
| Browser breadcrumbs | ✔: in replay events and telemetry | ✔: automatic |
| Value frequency | ✔: Typicality column | ✘: not observed |
| Request replay | ✔: curl command | ✘: not offered |
| Browser to server link | ✘: separate items | ✘: separate applications |

**Verdict: Mixed.** Raygun's request-scoped breadcrumbs make a server error easier to read. Rollbar's curl replay makes it faster to reproduce, and its source maps upload by script on the trial.

[summary]
<iframe width="100%" class="aspect-video h-auto" src="https://www.youtube.com/embed/7tQ7haFmSXI" title="Explore Traces | Better Stack" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

Rollbar filed the failed checkout and its server crash as unrelated items, and Raygun put them in different applications. I ran the same visit through Better Stack, and it showed both halves on one session timeline: the replay, 30 browser spans and 7 server spans from the same shopper.

![Better Stack session timeline with browser and server spans](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/719b53e1-6b61-4f23-7134-6ae81a884200/md1x =1512x744)

The backend service shows as "unknown" because my Sentry SDK setup sends no service name, but the spans line up under the click that caused them.

Going the other way works too. From a server error, the "View related" menu opens that request's logs, spans, release or the shopper's session replays:

![Better Stack View related menu on an exception](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/ce47c48a-1994-403d-81ed-31cd269b1800/public =1512x744)

You go from a server crash to the browser session behind it in one click, with no guessing which item matches which.

**[Connect browser errors to their server causes](https://betterstack.com/tracing)**
[/summary]

## Error grouping

Grouping decides whether one bug shows up as one entry. Get it wrong and your error count stops meaning anything after a deploy.

Both tools grouped the first release almost cleanly. The bad release, whose checkout code changed the shape of old stack traces, tested them much harder.

### Raygun: Values in messages create new groups

In release 1.0.0, the storefront's failed book loads came from one bug with different book IDs in the URL. Raygun gave each URL its own group:

![Raygun browser groups split by URL](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/bf6de6d2-53c1-4f5a-0577-355ead5de300/orig =1512x744)

Look at the `ApiError` rows for `/books/0`, `/404`, `/99` and `/1234`. The order tracking 404 also carried a changing ID in its URL and still stayed in one group, so message text doesn't explain every decision.

Release 1.2.0 made the pattern clearer. The new payment error split by amount:

![Raygun payment error split by amount](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/f449ecc5-260a-4bb0-c187-b218c0664500/lg2x =1512x744)

"Payment gateway rejected charge of 44 USD" has 8 events and the 35.5 USD version has 2. Both share the class and the stack, `server.js:173` called from `server.js:163`, so Raygun's Node.js grouping clearly includes the message.

The same release also opened a new group for the discount `TypeError` and two for the out-of-stock error, next to the old ones. The 1.2.0 deployment page counted all of it:

![Raygun deployment 1.2.0 with five new errors](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/d7b8fb10-d695-48db-9e8f-3ce679290800/md1x =1512x744)

"New errors 5" counts both payment groups and three copies of older bugs, although the release introduced only one new bug.

### Rollbar: Framework frames create new items

Rollbar grouped release 1.0.0 correctly, with one item per bug. In release 1.2.0, the checkout waits on slow queries before the bug fires, and how much of the Express stack survives changes from request to request.

The items list after 1.2.0 traffic shows the result:

![Rollbar items list after the bad release](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/95c4e870-6534-4c6a-c0c0-5684c6dea500/md2x =1126x736)

The payment error appears twice, as #13 and #14, and the discount `TypeError` now spans #2, #15 and #16. All three discount items are thrown from `server.js:150:44`, and they differ only in how many non-project frames sit underneath.

The version page for 1.2.0 shows the effect on counts:

![Rollbar version page for the bad release](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/ff92c341-f5c8-4d5f-9121-1ab240c9f300/public =1126x736)

The "New" tab says 5, which mixes one new error with repeats of old ones. The out-of-stock error and the recommendation timeout also got fresh items, #12 and #17, instead of reopening.

### What the bad release did to both

| Error in release 1.2.0 | Rollbar | Raygun |
|---|---|---|
| New payment error | 2 items, split by framework frames | 2 groups, split by amount |
| Coupon crash | Original plus 2 new items | Original plus 1 new group |
| Out-of-stock error | 1 new item instead of a reopen | Original plus 2 new groups |
| "New" count for the release | 5 | 5 |

Both results come from how each default works in my app. Rollbar's fingerprint includes framework frames under your code, and Raygun's Node.js grouping includes the message, so stacks that vary or messages with values in them produce new entries.

Neither result proves one tool groups worse everywhere. Rollbar offers Custom fingerprinting and a Merge action, and Raygun offers custom grouping. You can read more on Rollbar's grouping and triage controls in [our BugSnag vs Rollbar comparison](https://betterstack.com/community/comparisons/bugsnag-vs-rollbar/).

### Error grouping comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| Release 1.0.0 grouping | ✔: one item per bug | Split one browser error by URL |
| Grouping key in this test | Stack, including framework frames | Message, including values |
| New payment error in 1.2.0 | ✘: 2 items | ✘: 2 groups |
| Old bugs after code changes | ✘: new items | ✘: new groups |
| Grouping controls | Custom fingerprinting, Merge | Custom grouping |

**Verdict: Neither.** Each tool split the one new bug in two and duplicated old bugs after the code changed. Both need grouping rules before their release counts mean much.

## Real user monitoring and session replay

The two tools answer different questions about your users. Rollbar records what a shopper did before an error, and Raygun measures how fast the store felt for them.

### Rollbar: Video replay on the error page

Rollbar plays the recording inline on the item, in its "Session replay & telemetry" panel:

![Rollbar replay player and events on an item](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/ed33ca67-0899-42f5-b760-b845ec27cf00/public =1126x736)

Playback speed and inactivity skipping are built into the player, with an event list next to it covering page changes, clicks and their CSS selectors, and network calls with status and timing.

The same event list links to other errors from the visit:

![Rollbar replay events linking another item](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/668093ac-9b18-44e8-ddd1-203c96323c00/lg1x =1126x736)

Here `#1 ApiError GET /orders/tracking 404` appears in the timeline as a link, which is as close as Rollbar gets to joining events.

The Replays page lists every recording in the project:

![Rollbar Replays page](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/40689c19-f664-449c-2e6f-858eeb93ae00/md2x =1126x736)

Each row shows the starting URL, linked occurrences, browser, person, duration and trigger. Since the headless shoppers move quickly, none of my recordings lasted longer than 0 to 15 seconds. The setup page says every account gets 1,000 free replays a month.

Rollbar also has a People page, though it doesn't merge the two sides of the app:

![Rollbar People page with each person listed per environment](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/48bc67e3-dd3d-4653-ec3f-8ad27cfb2e00/md1x =1126x736)

Bob shows up as two people, one in production with 5 items and 39 occurrences and one in development with 6 items and 32. My split environments caused that, but you'd hit the same thing with any per-environment setup.

Rollbar doesn't measure page speed. The slow book page produced no timings, and the broken cover image created no item.

### Raygun: Page speed per route, with session timelines

Raygun's Real User Monitoring opens on performance charts:

![Raygun RUM performance charts](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/d9343e44-1f3d-48b6-6568-7b2b205a6600/lg2x =1512x744)

The tab covers load time, first paint, first contentful paint, LCP, FID, CLS and INP, plus custom timings.

The page and request tables are where my planted slow spots showed up:

![Raygun RUM pages and requests by speed](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/8d2e11d4-6849-4e4a-b7ce-2a8e85443300/md1x =1512x744)

The home page loaded in 285 ms on average, while book pages took 1.58 s. Among requests, `/search` averaged 1.49 s and `/prices/*` 2.63 s, which matches two of the problems I built in.

One catch is that Raygun folds `/books/3` into `/books/*`, so you can't single out the slow book page without drilling in.

The Customers page rolls sessions and errors up per person:

![Raygun Customers page with sessions and errors per user](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/6dfc9c44-2d6e-46b5-710c-a58dd900ee00/md2x =1512x744)

alice has 10 sessions and 5 errors, so you can tell how often one customer runs into trouble.

Opening a session shows where that person went:

![Raygun RUM session timeline for one user](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/9a5b9225-c5a0-4a6a-df9c-f1478bf76d00/lg2x =1512x744)

You get page views, time on each page, error and load-time counts and an "Experience: Excellent" label. There's no video, so you can see which pages a shopper visited but never what they clicked.

### Real user monitoring and replay comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| Video session replay | ✔: inline on the error | ✘: not offered |
| Session timeline | ✔: replay events | ✔: pages and time on page |
| Page load timing | ✘: not offered | ✔: per route |
| Core Web Vitals | ✘: not offered | ✔: LCP, CLS, INP |
| Request timing | Status and timing inside replays | ✔: per request path |
| Per-user view | People page, split by environment | ✔: Customers page |
| Free allowance | 1,000 replays a month | 5,000 RUM sessions with the error plan |

**Verdict: Rollbar for replay, Raygun for RUM.** If you need to watch what a user did before a crash, Rollbar has it on the error page. If you need to know which pages are slow for real visitors, only Raygun measures it.

[summary]
<iframe width="100%" class="aspect-video h-auto" src="https://www.youtube.com/embed/kf97nwgL88M" title="Building Charts with SQL | Better Stack" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

Rollbar recorded replays with no timings, and Raygun measured pages with no replay and no view of the server. In Better Stack I got both, plus the link between them. Its RUM Insights box took a plain question about the slowest route and answered with LCP p50 714 ms, p75 1948 ms and p90 3663 ms for `/#/orders` over 8 loads.

![Better Stack RUM Insights ranking routes by LCP](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/628945e8-106c-4816-c410-cf3b04d0d300/md1x =1512x744)

It traced the slow loads to the server being starved by my CPU-heavy `/search`, which Raygun's page charts couldn't explain. It wasn't perfect: it misread `/prices` as slow handler code, and the run cost $0.62.

Each session also keeps a full replay, with requests, handled errors, custom events such as "added to cart" and console output in one list:

![Better Stack session replay with its event list](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/72ca949e-10b9-4139-a43b-547df1896d00/lg2x =1512x744)

That's Rollbar's replay and Raygun's speed data in one place, tied to the backend spans of the same visit.

**[See page speed, replays and traces together](https://betterstack.com/tracing)**
[/summary]

## Release tracking and regressions

Release tracking answers two questions: did this deploy cause the problem, and has a fixed bug come back? Both tools tag errors with the version your SDK sends, and both treat deploys as a separate record. The trial made the biggest difference here.

### Rollbar: Deploys by API and a suspected deploy on every return

I resolved the coupon crash for version 1.1.0 from the Resolve dropdown:

![Rollbar Resolve dropdown with a version and comment](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/8999b801-572d-48aa-eef9-82135151a300/md2x =1126x736)

The dropdown takes a "Revision or version number" and a comment, here "Coupon lookup fixed in 1.1.0", then "Resolve and post".

Rollbar's deploy API accepted the project token, and each deploy appeared as a row in the items list:

![Rollbar items list with an inline deploy row](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/98e0c1b2-96fd-4935-d57e-fc0a30b72300/lg2x =1126x736)

The row reads "stanley deployed monitoring-lab to development, revision 1.1.0". I took this during a false start when the app was still running 1.0.0, and Rollbar kept the coupon crash resolved while 11 more 1.0.0 events arrived, because a fix for 1.1.0 ignores older versions.

When 1.1.0 really shipped, only the coupon crash reopened. The list gives no sign of it:

![Rollbar items list after release 1.1.0](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/4f6b6825-fdb1-455b-a682-8c76f6f04e00/lg2x =1126x736)

The row just turns active again. The "New / Reactivated" filter works by timeframe, so with a 1-hour or 7-day range every item from my test counts as new.

The item page is where Rollbar shines:

![Rollbar item reactivated with a suspected deploy](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/520aea87-9384-4cf1-ae8f-918a2f454700/orig =1126x736)

Next to "Reactivated version: 1.1.0" and "Occurrences since last reactivated: 9", it names "Suspected deploy: 45859437" and links to it. The new payment error in 1.2.0 got a suspected deploy too, so you can answer "should we roll back?" without leaving the error.

The version page for 1.1.0 sorts the release's errors into tabs:

![Rollbar version page for 1.1.0 with one reactivated item](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/979fb22f-3731-45e2-39b5-4a1c01115d00/lg1x =1126x736)

New 0, Reactivated 1, Still active 4, Resolved 1 and Commits 0. The coupon crash sits under Reactivated with its 9 occurrences. Commits and "Changes since previous deploy" stay empty until you connect source control.

Rollbar can also clear the list on every deploy. "Auto-resolve on deploy" is set per environment, and I turned it on for development before 1.2.0:

![Rollbar Auto-resolve on deploy enabled for development](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/92dbbcef-ce7c-479c-7f41-97bb00541f00/public =676x442)

Both auto-resolve options ship disabled, so this is a choice you make.

The 1.2.0 deploy resolved all six server items at once:

![Rollbar items resolved by a deploy](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/65889c42-3864-42b8-203d-da08e2271000/lg1x =1126x736)

That includes bugs I never fixed, such as the missing-book `TypeError` and the 503. Browser items stayed active because they report "production". Each release starts clean, and the cost is that a rare, unfixed bug drops out of view until it fires again.

When 1.2.0 traffic ran, the version page caught three of them coming back: the missing-book crash with 18 occurrences, the 503 with 6 and the report job with 1.

### Raygun: A clearer resolve dialog, and deployments by hand

Raygun's resolve menu has more options than Rollbar's:

![Raygun resolve options](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/95a62a56-821c-4622-b3d1-024a3f037800/lg2x =1512x800)

You can resolve, ignore, permanently ignore, resolve in a named version or resolve in the next version.

"Resolve in next version" adds a checkbox Rollbar doesn't have:

![Raygun Resolve in next version dialog](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/adf3374d-200d-4b29-0618-3ae68da09800/public =1512x800)

"Discard future occurrences until a newer version is released" comes pre-ticked, which means stragglers from the old version no longer count after you resolve.

Deployments were harder. Raygun's deployment API also needs a Personal Access Token, so on the trial I used the form:

![Raygun Create deployment form](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/d38b70f7-7129-4a75-489d-2272d6cdcc00/lg2x =1512x800)

It asks for the version, deployment time, author, email, commit and release notes.

My first save failed:

![Raygun Create deployment returning a 500 error](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/d474694a-a147-4d78-8d06-0fa2860b2900/lg1x =1512x800)

That attempt set "Deployed at" through the date picker. The second save, with only the version filled in, worked and showed the author as "Unknown".

The 1.1.0 test also needed three runs. In the first two, the coupon crash arrived as "Unknown error" because `raygun-apm` was still installed, so the resolved group never reopened. After I uninstalled the package, the third run worked:

![Raygun coupon error active again on 1.1.0](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/ef05d28b-83c8-4062-7aa4-bc2f80839d00/md2x =1512x744)

The coupon `TypeError` is Active again, on version 1.1.0, and it was the only error to reopen.

Further down the page, the activity feed records the return:

![Raygun activity feed with Error reoccurred](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/dc7c9f97-e489-42e1-a3e9-e55df8387d00/orig =1512x744)

"Error reoccurred on Oct 23rd 6:24:38 am" sits under the resolve entry, next to a version split of 57% on 1.0.0 and 43% on 1.1.0, with 19 instances in 1.1.0.

The deployment page for 1.1.0 files it under its own tab:

![Raygun deployment page with the coupon error under Regressions](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/842b125a-8f2f-4ff6-7d00-292dfa2d4500/public =1512x744)

Regressions shows 1, the coupon crash marked "Resolved in 1.0.0" and now Active. "Still occurring" showed 8, inflated by leftover groups from my two broken runs.

The errors list is less helpful:

![Raygun errors list after 1.1.0 with a deployment marker](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/5b8deda2-3dcd-4859-e050-e7c852be0d00/orig =1512x744)

The chart gains a Deployments marker strip, while the rows carry no regressed label. Raygun has no setting to resolve everything on deploy that I could find.

### Release tracking comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| Deploys on the trial | ✔: API with project token | Form only, failed once |
| Resolve for a future version | ✔: version and comment | ✔: next version, with discard option |
| Ignore old-version events | ✔: automatic for a later version | ✔: discard checkbox |
| Reopened label in the list | ✘: row turns active | ✘: row turns active |
| Regression detail | ✔: suspected deploy | ✔: activity feed |
| Per-release view | ✔: version page with Reactivated tab | ✔: deployment page with Regressions tab |
| Suspected deploy on new errors | ✔: yes | ✘: not offered |
| Auto-resolve on deploy | ✔: per environment | ✘: not found |

**Verdict: Rollbar.** Its suspected deploy was the most direct regression signal either tool gave me, and its deploy tracking worked on the trial. Raygun's discard checkbox is handy, but without API access its deployment pages meant manual and error-prone work.

[summary]
<iframe width="100%" class="aspect-video h-auto" src="https://www.youtube.com/embed/-26mmryojE4" title="Error tracking | Better Stack" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

Both tools hid the reopened coupon crash in their lists, Raygun made me register every deployment by hand, and both split the bad release's new error in two. I tested the same releases in Better Stack. It read the release from the SDK with no deploy call, and it flagged the return with a red "Reoccurred" status right in the errors list.

![Better Stack errors list with the coupon crash marked Reoccurred](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/a4c8af6b-7733-40f5-93ac-a059feb27800/md1x =1512x744)

You see the regression without opening anything. Better Stack has no auto-resolve on deploy, so you won't get Rollbar's clean slate.

For 1.2.0, the release page counted 2 new errors, and the payment failure stayed one error with 10 exceptions across every amount:

![Better Stack release view for the broken version](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/4efbd0ed-fa74-42bd-4c75-bf5ad6f14c00/md1x =1512x744)

Where Rollbar and Raygun each reported 5 new errors for a release with one new bug, this count was close enough to act on.

**[See every regression the moment it returns](https://betterstack.com/error-tracking)**
[/summary]

## Performance monitoring

In release 1.2.0, checkout slowed to 3 to 5 seconds a request, and no exception fired because of the delay. A tool can only catch that by timing requests.

### Rollbar: No timing data at all

Rollbar caught the new payment error and tied it to the deploy:

![Rollbar payment error with a suspected deploy](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/4492adeb-c930-4fd2-e48e-07e03efd0200/md2x =1126x736)

"Suspected deploy: 45860037" and "First version: 1.2.0" are right, and nothing on the page says the checkout behind it took seconds.

Rollbar has no tracing, performance or web vitals product, so the slowdown never appeared anywhere. My app's slow-query warnings reached it only as console lines inside server telemetry.

### Raygun: Two products, and neither caught it

Raygun's RUM can compare releases. I compared 1.1.0 with 1.2.0:

![Raygun RUM Compare between the two releases](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/757fd276-0071-441d-730c-7fc49f77dc00/md2x =1512x744)

"1.2.0 is running 34.8% faster than 1.1.0 in median load time", with median page load down from 28.9 ms to 18.85 ms. Full page loads really didn't change, and the slowdown lived in the `/checkout` request, which Compare leaves out.

The RUM request table hinted at the problem. `/checkout` averaged 438.95 ms over 143 requests, up from 199 ms after 1.0.0, but a version filter link didn't apply, so that figure blends every release.

Crash Reporting had no timing either. The payment error page shows the class, version 1.2.0, the user and a two-frame stack:

![Raygun payment error page with a two-frame stack](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/fc7c1640-bc57-4add-d9dc-2964e6af2900/lg2x =1512x744)

`server.js:173`, then `async server.js:163`, with no source lines and no duration.

### Raygun APM: Tested in 1.0.0, then removed

I tried Raygun APM in release 1.0.0 only. It needs the `raygun-apm` package plus the Raygun APM Agent running beside your app, and I ran the agent in Docker from an image "last updated almost 3 years ago".

On macOS it failed out of the box with `Error: send EHOSTUNREACH 0.0.0.0:2799`, and Raygun's Node.js setup page doesn't mention the `RAYGUN_AGENT_HOST=127.0.0.1` setting that fixed it.

The overview then filled in:

![Raygun APM overview with Apdex and request speeds](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/bc3c92e3-30b3-402f-fc23-be9d9bc8bb00/md2x =1512x800)

Apdex was 0.94, with a median request of 83 ms and P99 at 4,754 ms. The request breakdown put Queries at 0 ms, because Raygun's Node.js APM doesn't support SQLite.

The slowest tables showed how little it could see:

![Raygun APM slowest tables with empty methods and queries](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/cbcb24cf-acd6-4f6b-54bb-83310b380f00/lg2x =1512x800)

POST /checkout tops the requests at 3,545 ms, while "Slowest methods" and "Slowest queries" are empty. The only external call listed is Raygun's own crash upload to `api.raygun.io`, at 1,243 ms, and my calls to the price service don't appear.

Only some requests become traces:

![Raygun APM trace sampling settings](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/1fce25b1-9fcb-46a9-315e-a85d2376f700/lg2x =1512x744)

The default is "Sample 1 trace every 1 minute per URL", which is why POST /checkout had a single trace. You can add overrides per URL.

The slowest trace, GET /prices/5 at 5,298 ms, didn't explain itself:

![Raygun APM flame chart for a slow price lookup](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/07116cd5-8dcb-4e65-fc78-673ae7c7ef00/orig =1512x800)

The bar sits over "(garbage collector)" and "(idle)" blocks, with none of my functions. The profiler hooks `require` and my app uses `import`, and the real cause, waiting on the price service, shows up as idle time.

Then came the bigger problem. Installing `raygun-apm` broke Crash Reporting:

![Raygun Crash Reporting showing Unknown error after installing raygun-apm](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/5b265f81-f83e-42bd-77ac-f9b1f3ec7500/md1x =1512x800)

The coupon and missing-book crashes merged into one "Unknown error" group with an empty message and stack, 152 events by the end of my second 1.1.0 run. It happened with the profiler switched off too.

Reading both packages explained it. With `raygun-apm` installed, the `raygun` 2.2.10 SDK loads a bridge module that replaces JavaScript's global `Error`, so errors Node throws itself no longer pass `instanceof Error` and get sent empty.

Uninstalling the package, or setting `RAYGUN_APM_CRASH_REPORTING_INTEGRATION=false`, fixed it. I uninstalled APM before 1.1.0 and 1.2.0, so APM never had a chance to see the bad release. Given its missing SQLite support, it couldn't have shown the slow query anyway.

### Performance comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| Page load timing | ✘: not offered | ✔: RUM, per route |
| Request timing | ✘: not offered | ✔: RUM request table, all versions blended |
| Release comparison | ✘: not offered | RUM Compare, page loads only |
| Checkout slowdown in 1.2.0 | ✘: not visible | ✘: not visible, APM uninstalled |
| Server tracing | ✘: not offered | APM, tested in 1.0.0 only |
| SQLite query visibility | ✘: not offered | ✘: not supported by Node.js APM |
| Extra moving parts | None | Agent process next to the app |
| Side effects | None observed | APM package broke Crash Reporting |

**Verdict: Raygun, with caveats.** Its RUM pointed at real slow pages and requests, which is more than Rollbar can show. Read its release comparison with care, and test APM next to Crash Reporting in staging before you trust either. For what request tracing catches in the same scenario, see [our Sentry vs Raygun comparison](https://betterstack.com/community/comparisons/sentry-vs-raygun/).

[summary]
<iframe width="100%" class="aspect-video h-auto" src="https://www.youtube.com/embed/XJv7ON314k4" title="Live Tail Overview | Better Stack" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

Rollbar was blind to the slowdown, Raygun's comparison called the broken release faster, and Raygun's agent mostly recorded idle time before it had to come out. I ran the same bad release through Better Stack. It needed no agent, picking up traces from the Sentry SDK the API already used, and one click from the payment error opened the request's spans.

![Better Stack spans for a failing checkout with the slow query](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/6e59bd17-1ba1-432a-9a2e-6686c91c5700/lg2x =1512x744)

Of that checkout's 2.19 s, `SELECT book for checkout` used 1.53 s and the new "charge card" step 660 ms. The Service column is empty because my setup sends no service name.

Clicking "View logs" from that error took me to Live tail, narrowed down to the one request:

![Better Stack Live tail for the failing request](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/2244f741-0b0e-43f9-8c69-d2cd2b96c700/lg1x =1512x744)

My app's slow-query warning sits right before the failure, so the timing and the explanation arrive together.

**[Find the slow query behind a bad release](https://betterstack.com/log-management)**
[/summary]

## Logs and events

Neither tool stores application logs. When my app printed slow-query warnings, neither could count them, search them or link them to the release.

### Rollbar: RQL over error occurrences

Rollbar's Analyze page runs RQL, an SQL-like query language over error occurrences:

![Rollbar RQL counting occurrences by item](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/796e57ff-f9a9-47a0-f77c-5b41ee549c00/orig =1126x737)

A `GROUP BY item.counter, item.title` query returns counts per item, and the editor applies SQL's usual GROUP BY rules. It also offers templates, CSV download and a Metrics API.

RQL is useful for slicing errors, but it only sees occurrences. Console lines reach Rollbar only as telemetry attached to an error, and the pricing page lists RQL under the Advanced plan.

Search is a free-text box with its own syntax. `person.email:...` returned nothing, while the documented `email:"bob@example.com"` returned bob's 2 items.

### Raygun: No log store

Raygun collects errors, RUM sessions and APM traces, and none of its products stores general logs. To count my slow-query warnings by release, you'd need a separate logging tool.

### Logs and events comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| Application log storage | ✘: needs another product | ✘: needs another product |
| Query language | ✔: RQL over occurrences | ✘: not offered |
| Console lines | Inside server telemetry | ✘: not captured |
| CSV export | ✔: from items and RQL | Not tested |

**Verdict: Neither.** Rollbar's RQL is a handy way to slice errors, but neither tool could have shown you the slow-query warnings that explained my bad release.

## Uptime, status pages and alerts

I didn't find uptime checks or status pages in either product. I didn't test alert delivery in either tool, so this section covers what I saw in the settings.

### Rollbar: Eleven email rules by default

Rollbar's project sends email under 11 default rules, including new items, reactivated items, deploys, a high occurrence rate of 10 in 5 minutes and a daily summary. Other channels include Slack, Jira, PagerDuty, Opsgenie, Datadog and webhooks.

Snoozing an item is how you quiet it:

![Rollbar snooze options by time](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/830e2dde-a18f-464d-a372-4812e48eb100/md2x =1126x737)

You can snooze for 1 day, 1 week, 1 month, 3 months or a custom time, and the tooltip says snoozing stops notifications. There's no option to snooze until an error happens a certain number of times.

### Raygun: Notification defaults per application

Raygun sets notification defaults when you create each application:

![Raygun Create application form with notification defaults](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/d5aabc2d-f04a-44e0-bce5-f46974179500/lg1x =2238x1566)

By default you get emails for new errors, a daily summary and a weekly RUM update, with APM alerts switched off. Because each part of your app is its own application, you set this up once per application.

### Alerting comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| Uptime monitoring | ✘: not found | ✘: not found |
| Status pages | ✘: not found | ✘: not found |
| Default email alerts | ✔: 11 rules | ✔: new error, daily summary, weekly RUM |
| Snooze | By time only | Not tested |
| Alert delivery | Not tested | Not tested |

**Verdict: Not compared.** Both send email alerts by default, and I didn't test delivery in either. If you need uptime checks or a status page, plan on another product with either tool.

## AI-assisted debugging

I didn't run either tool's AI, so this section describes what each offers and isn't a head-to-head.

### Rollbar: Root cause analysis on credits

Rollbar's "Analyze root cause" button opens a "Root cause & fix" tab. On my trial it asked me to "Connect all GitHub repos" before it would start, and the credit counter read 0 of 15k used.

Rollbar puts a typical analysis at 500 to 700 credits, and paid plans include some. Its documentation also describes a beta step that turns an analysis into a pull request. The RQL editor has an AI assistant as well, which I didn't use.

### Raygun: An MCP server for outside assistants

Raygun offers a remote MCP server at `https://api.raygun.com/v3/mcp`, with OAuth sign-in. An outside assistant such as Claude Code, Cursor or Codex connects to it to look into errors, deployments, sessions and APM data.

Raygun's documentation also describes AI Error Resolution, which sends an error to a model using your own OpenAI or Azure OpenAI key. Raygun's pricing page lists it on every Crash Reporting plan, but I didn't open it during my test.

### AI comparison

| Capability | Rollbar | Raygun |
|---|---|---|
| In-app analysis | ✔: Analyze root cause | AI Error Resolution, per docs |
| Requirement seen on trial | GitHub connection | Not tested |
| Model billing | Rollbar credits | Your own OpenAI or Azure OpenAI key |
| MCP server | ✔: available | ✔: remote, OAuth |
| Accuracy | Not tested | Not tested |

**Verdict: Not compared.** Rollbar's AI runs on its own credits and wants your repository, while Raygun's options run through your assistant or your model key. Try both on your own errors before you pick on this basis.

[summary]
<iframe width="100%" class="aspect-video h-auto" src="https://www.youtube.com/embed/n6TtDk8ITgc" title="AI SRE Demo | Better Stack" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

Rollbar's analysis wouldn't start without GitHub, and Raygun's routes go through a model key or an outside assistant you bring. I gave Better Stack's built-in AI SRE the bad release with no repository connected and asked what changed since 1.1.0.

![Better Stack AI SRE comparing 1.1.0 and 1.2.0](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/156c28b3-08a9-4423-a025-fac33aa2c700/public =1512x744)

It spotted the checkout p50 climbing from roughly 2 ms to roughly 3.7 s, pinned that on `SELECT book for checkout` moving from 0.13 ms to 2.6 s, and cleared the database since the other statements all held near 0.1 ms.

The second half of the answer covered the new error:

![Better Stack AI SRE explaining the bad release](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/d67d2cf1-42cc-4c6c-7ae5-c4820e0d0900/md1x =1512x744)

It linked the "charge card" step, failing 10 of 48 calls on 1.2.0 only, to the `PaymentGatewayError` and recommended a rollback. The run took about four minutes and cost $0.49, and since I didn't run either competitor's AI, treat this as one result from one test.

**[Hand your next bad release to AI SRE](https://betterstack.com/ai-sre)**
[/summary]

## Pricing

Rollbar sells one error tracker in volume tiers, while Raygun prices Crash Reporting, RUM and APM as separate products. The figures below come from each vendor's pricing page on October 23, 2026, so check both before you buy.

### Free plans and trials

| Feature | Rollbar | Raygun |
|---|---|---|
| Permanent free plan | ✔: yes | ✘: none |
| Free errors | 5,000 occurrences a month | Not applicable |
| Free replays | 1,000 a month | Not applicable |
| Free users | Unlimited | Not applicable |
| Free retention | 30 days | Not applicable |
| Trial | 15 days of Advanced, no card | 14 days on any plan |
| Trial allowance | 200,000 occurrences, 10,000 replays, 15,000 credits | Not listed |
| API tokens on the trial | ✔: available | ✘: Personal Access Token blocked |

My Rollbar trial drops to the Free plan on its own when it ends, so you can keep using it without paying.

### Entry-level paid plans

| Feature | Rollbar Essentials | Raygun Crash Reporting Basic | Raygun RUM Basic | Raygun APM Basic |
|---|---|---|---|---|
| Billed monthly | From $9 a month | $60 a month | $120 a month | $120 a month |
| Billed annually | About 17% less | $40 a month | $80 a month | $80 a month |
| Included volume | From 10,000 occurrences | 100,000 errors | 100,000 sessions | 100,000 traces |
| Users | Unlimited | Unlimited | Unlimited | Unlimited |
| Retention | 90 days | 180 days | Not published | Not published |

Rollbar's price rises with the volume you choose on its slider. Advanced starts at $13 a month and adds RQL and 180-day retention.

Raygun's Crash Reporting plan includes 5,000 RUM sessions and 5,000 APM traces at no extra charge.

### What costs extra

| Need | Rollbar | Raygun |
|---|---|---|
| More errors | Higher volume tier or on-demand events | $0.001 per extra error |
| More session replay | Higher replay volume | ✘: no video replay |
| Page performance | ✘: not offered | RUM product, $0.002 per extra session |
| Server tracing | ✘: not offered | APM product, $0.002 per extra trace |
| Logs | ✘: needs another product | ✘: needs another product |
| AI | Credit packs from 15,000 credits for $5 a month | Your own OpenAI or Azure OpenAI bill |

### Comparing the actual cost

For error tracking alone, Rollbar costs far less. Its free plan covers the whole team with replay included, and its first paid tier starts at $9 a month.

Raygun's Crash Reporting tier costs $40 a month billed annually, and it includes ten times Rollbar's starting volume and twice its retention. If your app throws a lot of errors, that gap narrows.

The bill grows once you want Raygun's strengths. Crash Reporting, RUM and APM on their Basic tiers come to $300 a month, or $200 a month billed annually, and APM also needs an agent you run yourself.

Neither tool covers logs, tracing that would have caught my slow checkout, or uptime checks, so plan for those on top. For errors, logs, uptime and on-call under one roof, read [our look at Rollbar against an all-in-one platform](https://betterstack.com/community/comparisons/better-stack-vs-rollbar/).

**Verdict: Rollbar for most teams.** Raygun pays off only if you'll use its RUM, since that's the part Rollbar can't replace.

## Full feature comparison

Here's every observation from the three releases, pulled into one table.

| Feature | Rollbar | Raygun |
|---|---|---|
| Browser and server in one place | ✔: one project | ✘: one application per part |
| Onboarding | One SDK at a time, stale tokens on a new project | One product at a time |
| Unhandled Node.js promise rejection | ✔: caught | ✘: missed in my setup |
| Handled or unhandled badge | ✘: level only | ✔: tags on browser errors |
| Browser source maps on the trial | ✔: script upload | ✔: manual upload per file |
| Server source lines | ✘: frames only | ✘: frames only |
| Server breadcrumbs | Process-wide telemetry | ✔: per request |
| Request replay | ✔: curl command | ✘: not offered |
| Browser to server link | ✘: separate items | ✘: separate applications |
| Grouping key in this test | Stack, including framework frames | Message, including values |
| New payment error in 1.2.0 | ✘: split into 2 items | ✘: split into 2 groups |
| Session replay | ✔: video on the error | ✘: session timeline only |
| Page and request speed | ✘: not offered | ✔: RUM |
| Core Web Vitals | ✘: not offered | ✔: LCP, CLS, INP |
| Per-user view | People page, per environment | ✔: Customers page |
| Deploys on the trial | ✔: by API | Form only, failed once |
| Resolve for a future version | ✔: version and comment | ✔: next version, with discard option |
| Reopened label in the list | ✘: row turns active | ✘: row turns active |
| Regression detail | ✔: suspected deploy | ✔: activity feed and Regressions tab |
| Auto-resolve on deploy | ✔: per environment | ✘: not found |
| Release performance comparison | ✘: not offered | RUM Compare, page loads only |
| Server tracing | ✘: not offered | APM, no SQLite support, tested in 1.0.0 |
| Slow checkout in 1.2.0 | ✘: not visible | ✘: not visible |
| Logs | ✘: not offered | ✘: not offered |
| Occurrence queries | ✔: RQL | ✘: not offered |
| Uptime and status pages | ✘: not found | ✘: not found |
| AI | Root cause analysis, untested | MCP server, untested |
| Free plan | ✔: unlimited users | ✘: 14-day trial |

## Which should you choose?

The choice comes down to whether you mainly need to fix errors or also need to know how fast your app feels.

### Choose Rollbar if errors and deploys are your main concern

Rollbar fits teams that want every error in one place and tied to the deploy that caused it. One project took my whole app, it caught every planted error, and its suspected deploy answered the rollback question on both the reopened bug and the new one.

Replay sits on the error page, the curl command reproduces server failures, and the free plan covers the whole team. Auto-resolve on deploy gives each release a clean list if you want one.

The trade-offs are real, though. Server telemetry mixes requests from different users, the default fingerprint split old bugs into new items once my code changed, and there's no performance data at all. Set up custom fingerprinting early, and budget for tracing elsewhere.

For how Rollbar compares with a tool that does trace requests, read [our Sentry vs Rollbar comparison](https://betterstack.com/community/comparisons/sentry-vs-rollbar/).

### Choose Raygun if you need real user monitoring

Raygun fits teams who need to know how fast pages and requests are for real visitors. Its RUM was the strongest part of my Raygun test, surfacing the slow book pages, search and price lookups I'd built in, and its request-scoped breadcrumbs kept server errors clean.

Its resolve dialog and activity feed also record a returning bug clearly, and the Customers page shows how often each person runs into trouble.

Expect more work in return. You manage a separate application for each part of your system, the trial's token restriction turns source maps and deployments into manual chores, and the APM package broke Crash Reporting in my Node.js setup. Test APM in staging first, and don't take the release comparison at face value.

To see how Raygun fares against a tool with built-in logs, read [our Raygun vs Honeybadger comparison](https://betterstack.com/community/comparisons/raygun-vs-honeybadger/).

## Final thoughts

Rollbar and Raygun failed my bad release in the same two ways: neither saw the slow checkout, and both split its new error in two. The real decision is which kind of help you want around those gaps.

Rollbar keeps everything in one project and ties each error to a deploy and a replay, for very little money. Raygun measures more of what your users feel, and leaves you to join the pieces across separate applications and products, with its own release comparison calling the broken release faster.

If the question you ask most after a deploy is "what broke?", Rollbar answers it on its free plan. If it's "why does the store feel slow?", Raygun is the only one of the two that even times the page, and **neither will point at the query that did it**.