TrackJS vs Raygun: A Hands-On Error Tracking Comparison for 2026

My test app's worst release slowed checkout from about 15 ms to over 4 seconds and started failing card payments. TrackJS's Versions page showed it with the fewest errors of all three releases. Raygun's RUM comparison went further and called it "34.8% faster" than the release before. Both tools were reading real numbers, and both pointed the wrong way.

That shared blind spot says something about each product. Neither measured the one request that broke, so everything else in this comparison is about what they do see.

TrackJS is a front-end JavaScript error monitor with a lighter Node.js agent, a telemetry timeline on every error, and a built-in AI Debugger. It bills by page view and doesn't charge for errors.

Raygun splits monitoring into three products you buy one by one, for crashes, real users and server performance. Each part of your app, such as the API and the storefront, becomes its own application with its own key and error list.

I put both through the same intentionally broken bookstore in late October 2026. You'll see them weighed on setup, error capture, debugging, the path from browser to server, grouping, real user monitoring, releases and regressions, performance, logs, alerts, AI and pricing.

TrackJS vs Raygun: Results at a glance

These results come from my Express and Vite setup, with source maps on localhost. A public build, a paid Raygun plan with API tokens, or a CommonJS app could change a few calls.

How I tested TrackJS and Raygun

My test subject is a small online bookshop that misbehaves on cue. It has an Express API over SQLite, a Vite storefront that routes by hash, a stub price service and a nightly-style report job. Headless Chromium sessions acted as shoppers, so both tools faced the same failures in the same code.

The problems I seeded:

• Front-end crashes: a wishlist click that reads from null, and API failures that the storefront reports.
• Back-end crashes: an unrecognized coupon at checkout, a lookup of a book that doesn't exist, and an out-of-stock order.
• A shaky upstream: the price service sometimes replies 503.
• Async failures: a recommendations promise that rejects with no handler, plus a report job that throws.
• Last-release extras: a slow book query in checkout and a payment bug, both off until the third version.

The three versions

Version 1.2.0 is the one to watch. It combined a slowdown with a new error on a single request, the pattern a real bad deploy usually follows.

SDKs and test limitations

• Scope: TrackJS sells browser error monitoring with a Node.js add-on. I judged its tracing and logs gaps as outside its scope, and held it to account for its own features.
• Counts: each tool received its own traffic runs, so totals don't line up one to one.
• Localhost source maps: TrackJS can only fetch maps from public URLs, so it had manual mode only. Raygun's API uploads need a paid token, so it had manual uploads only.
• Raygun APM: the APM profiler wraps require, and my app uses ES modules, which limited what its traces could show.
• No alert channels and no repository: neither tool had a notifier connected, and neither AI could read my code.

Terms in each tool

Setup and onboarding

TrackJS gives you one application for the whole app and two small agents. Raygun asks for one application per part of your stack and sets up one product at a time. Each had a trap in its documented path, and both were serious.

TrackJS: Simple install, broken Express handler

The browser agent goes in with a script tag or an npm import:

Onboarding runs through Agent, Applications, Team and Ignore. The application key fills in from the name as you type, and keys can't be edited later:

My own typing doubled the key here, so the fix was a new application.

The server agent was the real problem. Version 1.3.0 of trackjs-node drops whatever options you hand to its Express error handler. Once a route fails with a 5xx, it reports the error and never calls next(), so the request hangs with no response. I reproduced it on a bare Express 5 server, then wrapped the handler to pass the error on myself:

export function afterRoutes(app) {
  const handler = TrackJS.Handlers.expressErrorHandler();
  app.use((err, req, res, next) => {
    let passed = false;
    handler(err, req, res, () => {
      passed = true;
      next(err);
    });
    if (!passed) next(err);
  });
}

The highlighted line is the workaround. Without it, every checkout that failed with a 500 timed out in my test.

Raygun: One app and one product at a time

Raygun's onboarding sets up one application and one product per pass, and it waits for a first event before letting you continue. My stack became two applications, monitoring-lab-api for Crash Reporting and monitoring-lab-web for Crash Reporting and RUM, each with its own API key.

Two problems took longer to find:

• The npm browser package didn't start in a lazily loaded module. raygun4js only reads its settings when the window's load event fires, and my module loaded after that, so it sat idle. I queued calls the way the CDN snippet does, then imported the library after load.
• Installing the APM package broke Crash Reporting. With raygun-apm installed, even with the profiler off, route crashes showed up as "Unknown error", stripped of both message and stack:

The cause is in the packages' own code. The crash reporter loads an APM bridge that replaces global.Error, so native TypeErrors fail instanceof Error and are sent empty. Uninstalling raygun-apm cured it, and so does the environment variable in the tip below.

Worth turning on in Raygun: if you add APM to a project that already uses Crash Reporting, set RAYGUN_APM_CRASH_REPORTING_INTEGRATION=false and check that a native error still arrives with its message.

Setup comparison

Verdict: Mixed. Each tool's documented setup broke something important: TrackJS's Express handler hung failing requests, and Raygun's APM package emptied native errors. TrackJS is quicker to install if you patch the handler. Raygun suits teams that want separate apps per service from the start.

Error capture

Both tools hook uncaught errors in the browser and in Node.js. They split on the failure that no code reported.

TrackJS: Every planted failure, plus extras

After a clean run, TrackJS held 99 errors in 29 groups:

Every failure I planted is there, including the unhandled rejection under the Express entry. TrackJS also adds errors you didn't ask for. It reports every failed fetch as its own Network Error, next to the app's own report of the same failure:

It also turns console.error lines into errors by default, which gave me a group for "Cannot set headers after they are sent". Expect extra rows until you tune those settings.

Raygun: Clean groups, one failure missing

Raygun's API application listed five groups:

The crashes, the 503s, the out-of-stock error and the report job are all there. The unhandled rejection is missing, even with reportUncaughtExceptions on. Browser errors went to the separate web application, which listed eight groups of its own.

Capture comparison

Verdict: TrackJS. It caught everything, including the rejection Raygun let through. Its defaults also double up browser failures, so a TrackJS list needs some pruning to read cleanly.

Debugging an error

A good error page shows the failing line and the steps that led to it. The two tools take different routes to that, and source maps decided much of it.

TrackJS: A rich timeline, maps that don't stick

TrackJS puts a telemetry timeline on every browser error:

Clicks with their element, hash navigations, fetches with status and duration, and the app's console lines sit in one list. An Errors on Page strip jumps between all errors from that page load, and Time On Page tells you how long the visitor had been there.

Source maps were harder. TrackJS fetches maps from the script's public URL, and on localhost it couldn't:

You can drop a .map file onto the stack trace to apply it:

With the map dropped in, the frame becomes line 122 of pages.js. The map lives in your browser tab, though, and a refresh brought the minified frames back.

Server errors in TrackJS list a file and line number, with no source and no request body. The telemetry includes this request's steps, but also startup and job console lines from minutes earlier.

Raygun: Maps that stay, breadcrumbs per request

Raygun took a manual upload per file on the trial:

Once uploaded, "Re-process this error for Source Maps" fixed the wishlist error for good:

Lines 119 to 125 appear, with the planted-bug comment. On the server, breadcrumbs stayed inside the request:

Only this checkout's two steps appear, with no noise from other shoppers. The stack itself showed server.js:150 and no code.

Debugging comparison

Verdict: Raygun, narrowly. Its source maps stayed applied and its server breadcrumbs belonged to the request. TrackJS's browser timeline is the better read, so a front-end team might reverse this call.

From the browser to the server

When a storefront call fails, you want the server error behind it. This is where TrackJS's small Node.js agent pays for itself.

TrackJS: A link on every request

Each fetch in TrackJS's timeline carries a link to the server errors from the same request:

The Node.js agent sets a correlation header, and the browser agent records it. Clicking the failing checkout's link opened the server's coupon error:

It's a true join without a tracing product. Because every fetch shows the link, even ones that succeeded, some clicks lead to an empty page.

Raygun: Two applications, no join

Raygun keeps the storefront and the API in separate applications with separate error lists. A browser ApiError and the server crash behind it never link up, and Crash Reporting has no tracing to connect them.

Browser-to-server comparison

Verdict: TrackJS. It went from a failed fetch to the exception it caused in one click. With Raygun, you match the two by time and guesswork.

Raygun can't connect its two applications, and TrackJS's link lands on a server error with no timing for the work behind it. A storefront visit in my Better Stack test came out as one timeline covering browser and API alike:

Notice the 30 frontend spans sitting above the 7 backend spans they triggered. A slow or failing step shows its duration on both sides, without opening a second tool.

Follow a visit from click to query

Error grouping

Grouping turns thousands of events into a short list. TrackJS groups by message text. Raygun's Node.js grouping also includes the message, so both split bugs whose messages carry values. They differ in how often.

TrackJS: A group for every value

TrackJS split anything with a variable in its message:

The out-of-stock error split by book and quantity, and every distinct list of IDs in the tracking URL became a group of its own. On 1.2.0, the payment error went the same way:

Each of the three failed charges got its own server group, and the browser added a fourth. Each had one event, so none of them grew into a trend.

Raygun: Fewer splits, still some

Raygun split the payment error too, by amount:

It made two groups, one with 8 events, so the larger group still showed a pattern. The 1.2.0 code change also opened duplicate groups for the coupon and out-of-stock errors, and the browser application split one ApiError by URL.

Grouping comparison

Verdict: Raygun, narrowly. Both split real bugs by their values, but TrackJS did it far more often. Raygun suits teams that can live with an occasional duplicate, and TrackJS suits teams willing to write grouping rules early.

TrackJS made one group per failed charge, and Raygun still split the same bug in two. In my Better Stack test, all 10 payment exceptions from 1.2.0 stayed in a single group:

Different amounts didn't matter, and the source for line 173 is right on the page. You watch one count climb, and nobody writes grouping rules.

Group errors by what broke

Real user monitoring and session replay

Measuring how pages load for real visitors is a paid Raygun product. TrackJS records a little about each page with an error and nothing else. Neither records video replays.

Raygun: Pages, requests and sessions

Raygun's RUM covers load time and Core Web Vitals:

Its virtual pages and XHR tables show where time goes:

The book pages averaged 1.58 s and the price requests 2.63 s. Raygun collapses /books/3 into /books/*, so finding one slow page means drilling in. Each user's sessions sit on a timeline:

It's a list of page views with timings, without a video.

TrackJS: Errors only

TrackJS counts a page view each time its agent starts, which in a hash-routed app means once per load. It shows Time On Page on errors, and no page timings or web vitals.

RUM comparison

Verdict: Raygun. It's the only one with real user monitoring. That costs extra, since RUM is billed as its own product.

Release tracking and regressions

After a deploy, you want new errors flagged and fixed ones caught if they return. TrackJS treats a fix as a label. Raygun treats it as a promise tied to a version.

The difference shows in what can move an error between states:

TrackJS's statuses never change on their own. Raygun reactivates a resolved error when it occurs in a newer version.

TrackJS: Fixed stays Fixed

TrackJS's Set Status menu offers labels:

I marked the coupon error Fixed and shipped it again in 1.1.0. It kept arriving, and it kept the label. The only sign was in its version chart:

The red 1.1.0 bar and "Versions Impacted 2" show the return, if you open the group. The dashboard's New Errors list meanwhile filled with message variants:

Nothing there pointed at the returning coupon error.

Raygun: Resolved in the next version, reopened on return

Raygun offers several ways to resolve:

Resolve in next version keeps older versions quiet and reactivates the error if a newer one reports it:

Its "Discard future occurrences" checkbox is ticked by default. When 1.1.0 brought the bug back, the deployment page sorted it into Regressions:

That's a release view that names the returning bug.

The returning bug in both tools

Here's the coupon error after 1.1.0 in each tool, trimmed to the parts that matter:

In TrackJS, the count at ① kept climbing while the label at ② still says Fixed. In Raygun, the activity feed records "Error reoccurred" at ① after my resolve at ②.

Worth turning on in TrackJS: enable New Errors and Error Rate Increases notifications, and check the version chart on any group you mark Fixed, because the label never changes by itself.

Worth turning on in Raygun: resolve with Resolve in next version and create a deployment for every release, so returning bugs land in the Regressions tab.

Release comparison

Verdict: Raygun. It reopened the bug, logged why, and listed it under the release that brought it back. TrackJS records your intent and nothing more, so a Fixed bug can return unnoticed.

TrackJS kept the returning bug labelled Fixed, and Raygun logged the reopen in an activity feed that the error list doesn't show. Better Stack got the same 1.1.0 release in my test and flagged the coupon error in the list itself, with a red "Reoccurred" status:

Only the returning error changed, and its activity feed records the reopen. Better Stack has no deployment records like Raygun's, but the regression shows at a glance.

Catch bugs that come back

Performance monitoring

A bad release usually shows first as slow requests. TrackJS doesn't measure performance. Raygun has RUM for the browser and APM for the server, and in this test both missed the slow query.

TrackJS: A duration inside one timeline

The only sign of the slowdown was a network entry in a failing checkout's timeline:

That checkout request ran for 4,073 ms; on the first release, the same call finished in roughly 15 ms. Successful slow checkouts left no trace, because TrackJS records nothing without an error.

Raygun: APM that couldn't see the app

Raygun's APM needs a separate agent next to your app. Its overview showed request timings:

The breakdown never got further than that. Slowest methods and slowest queries were empty, SQLite isn't supported, and the profiler's hooks miss ES module imports:

The real wait shows as "(idle)". In RUM, the /checkout XHR averaged 438.95 ms across all releases, with no working filter for 1.2.0, and RUM Compare looked at page loads only:

Its verdict, "1.2.0 is running 34.8% faster", came from page loads that the bad release never touched.

What each release view said about 1.2.0

Both tools have a page meant to tell you how a release went:

TrackJS counted fewer errors on 1.2.0 because fewer checkouts got through. Raygun measured page loads, which didn't change. Neither number covered the checkout request.

Performance comparison

Verdict: Raygun, narrowly. It has the tools, and its XHR table did show checkout getting slower overall. In my ES module app, though, neither product pointed at the cause, and its own release comparison praised the bad deploy.

Logs and events

Neither tool stores logs. TrackJS records console output in each error's timeline. Raygun keeps breadcrumbs, including the app's own, on each error.

On 1.2.0, TrackJS's server timeline did hold my app's own warning, [warn] slow query: SELECT book for checkout, 1.52 s before the payment error. That's the closest either tool came to the cause.

Verdict: Neither. You'll need a separate log store with either tool.

The slow-query warning existed only as one console line inside one TrackJS error, and Raygun had no logs at all. Better Stack handled the same failed checkout in my test, and its log link narrowed Live tail to that one request:

The failed checkout line sits next to the slow-query warning from the same request. The cause is one click from the error, in a log store you can also search later.

Search the logs behind every error

Alerts

TrackJS sends New Errors, Trending Errors and Error Rate Increases alerts, plus daily and weekly summaries, by email, Slack or Teams:

None of its alerts covers a Fixed error that returns, since New Errors keys on message text. Raygun's applications default to new-error alerts and daily summaries. I connected no channel to either, so I can't say how the alerts read.

Verdict: Not compared. Neither tool sent me an alert during the test.

AI-assisted debugging

TrackJS has an AI Debugger on every error. Raygun offers a remote MCP server for outside assistants, and its pricing page lists AI error resolution on Crash Reporting plans. I tested only TrackJS's, so this section isn't a head-to-head.

TrackJS: Careful, and clear about its limits

Opening the AI Debugger tab starts an analysis, with sanitized error data sent to OpenAI by default. On the payment error from 1.2.0, it took about 20 seconds:

It placed the failure at server.js:173 on 1.2.0 and ruled out a declined card or a bad coupon. It didn't find the every-fifth-charge counter, because it had no code to read. Its fix list was more interesting:

Its last suggestion treated the slow book lookup as a separate latency problem, so it didn't blame one issue for the other. On the wishlist and coupon errors, it gave hedged but reasonable hypotheses and said plainly that it lacked the source to decide.

Raygun: An MCP server, untested

Raygun has no assistant inside its interface. Its MCP server lets tools like Claude Code or Cursor investigate errors, deployments, sessions and APM data after an OAuth sign-in. I didn't test it.

AI comparison

Verdict: Not compared. TrackJS's AI Debugger was careful and useful within its limits. I didn't run Raygun's option, so there's no fair match.

TrackJS's AI Debugger saw one error at a time and missed the payment counter, and Raygun leaves the work to an outside assistant. Better Stack's AI SRE got a broader question from me, comparing the two latest releases, with no code connected:

It found the one slow query among fast ones and cleared the database host, then traced the card failures to 1.2.0 alone, at 10 of 48 charges. It took about four minutes and $0.49, far slower than TrackJS's 20 seconds, and it explained the whole release.

Ask AI SRE about your last release

Pricing

TrackJS charges by page view, keeps a set number of errors per minute, and never bills for errors. Raygun bills each product separately: Crash Reporting by errors, RUM by sessions and APM by traces.

I read TrackJS's and Raygun's pricing pages on November 6, 2026. Prices change, so confirm them before you sign up.

Free plans and trials

TrackJS's billing page showed my trial terms:

The trial ran free until November 11, with a Subscribe button and nothing else to configure.

Entry-level paid plans

Raygun RUM Basic and APM Basic each cost $120 a month, or $80 a month yearly, for 100,000 sessions or traces.

What costs extra

Comparing the actual cost

For error tracking alone, billed yearly, Raygun's Crash Reporting Basic is cheaper at $40 a month against TrackJS Starter's $45, and it keeps errors for 180 days against TrackJS's 10. TrackJS's bill doesn't move when a release throws thousands of errors, though, because it charges for page views and keeps 20 errors a minute.

The gap widens once you want more than errors. Raygun with RUM costs $120 a month yearly, and adding APM brings it to $200. TrackJS has nothing to add, so a TrackJS team buys performance monitoring elsewhere. Our Rollbar vs Raygun comparison looks at the same Raygun bill against a cheaper error tracker.

Verdict: Mixed. Raygun is cheaper per error with longer retention. TrackJS is the predictable bill for a busy front end that throws a lot.

Full feature comparison

Which should you choose?

Decide whether you need one focused tool for the browser or a broader set you'll pay for piece by piece.

Choose TrackJS if the front end is where things break

TrackJS reported each planted failure, linked each failed fetch to the server error behind it, and put a detailed timeline on every error. Its AI Debugger was careful, and its page-view pricing stays flat however many errors a release throws.

The gaps are real. Its Express handler needs a workaround, Fixed means nothing if a bug returns, message grouping splits bugs by their values, and it measures no performance. For TrackJS against a broader platform, see our Sentry vs TrackJS comparison.

Choose Raygun if you want release tracking and real user monitoring

Raygun reopened the returning bug and listed it under the release that caused it. Its source maps stay applied, its server breadcrumbs belong to the request, and RUM shows page and request timings across your users.

It's also fiddly. Each part of your app is a separate application with no link between them, the trial blocks API automation, and installing APM broke error reporting until I disabled its integration. For Raygun against another all-round tracker, read our Raygun vs Honeybadger comparison.

FAQ

Does TrackJS monitor Node.js servers?

Yes, with the trackjs-node agent. Wrap its Express handler as shown in the setup section, since version 1.3.0 leaves failed requests without a response.

Does Raygun have session replay?

No. Raygun's RUM shows each session as a timeline of page views and timings, without a video recording.

Which tool links browser errors to server errors?

TrackJS. Each fetch in its timeline links to the server errors from the same request. Raygun keeps the two in separate applications with no link.

Is Raygun cheaper than TrackJS?

For errors alone on yearly billing, yes: $40 a month for Raygun Crash Reporting against $45 for TrackJS Starter. Adding Raygun's RUM or APM costs $80 a month each on yearly billing.

Final thoughts

The choice is between a sharp tool and a broad kit. TrackJS sees everything that happens in the browser and connects it to the server, but a Fixed label in TrackJS is only a hope. Raygun watches more of the stack and remembers what you fixed, at the cost of separate apps, separate bills and setup traps.

Neither one caught the slow query that made 1.2.0 a bad release, and both release views told me it was fine. Whichever you pick, don't let its release page be the last thing you check after a deploy.

Got an article suggestion? Let us know

Explore more

LogRocket vs TrackJS: A Hands-On Error Tracking Comparison for 2026

LogRocket and TrackJS tested on the same buggy Node.js and Vite app across three releases, covering browser and server errors, source maps, session context, grouping, regressions, AI and pricing.

PostHog vs TrackJS: A Hands-On Error Tracking Comparison for 2026

PostHog and TrackJS tested on the same broken app across three releases: setup, source maps, grouping, regressions, slow queries, AI debugging and pricing, with verdicts on where each tool fits.

Sentry vs TrackJS: Hands-On Error Tracking Comparison for 2026

I tested Sentry and TrackJS on one Node.js and Vite app across three releases, comparing browser error context, source maps, grouping, releases, AI and pricing, with TrackJS judged as a front-end tool.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.