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

GlitchTip asks you to install Sentry's SDK. There's no GlitchTip package: you run npm install @sentry/node, paste a GlitchTip DSN in place of a Sentry one, and the same code reports to a different backend. That made this the cleanest comparison in my series, because both tools received identical events from identical library code.

What each backend did with those events was very different. My bad release produced one payment error with a changing amount in its message. Sentry filed it as one issue. GlitchTip filed seven, one per amount, each with a single event.

Sentry is a developer-focused monitoring platform with error tracking, browser-to-database tracing, session replay, logs, profiling, plus Seer, its built-in AI for root-cause analysis. GlitchTip is an open-source error tracker built to accept Sentry's SDKs, with basic performance averages, logs and uptime checks, which you can self-host or use as a hosted service from $15 a month.

The shared SDK also hid a trap. With the current SDK and GlitchTip's own setup snippet, GlitchTip's Performance page stayed empty, and the fix was a single option its docs don't mention.

I ran both on the same bookstore app in October 2026, with the same planted bugs and the same three releases. Below, they're compared on setup, capture, debugging, grouping, browser monitoring, releases, performance, logs, uptime, AI and price.

Sentry vs GlitchTip: Results at a glance

Each verdict comes from one Node.js app with my configuration, so treat each one as a result from my setup, not a general rule.

How I tested Sentry and GlitchTip

monitoring-lab is a small bookstore I built to fail on cue. It runs an Express 5 API on SQLite behind a Vite storefront, plus a deliberately flaky price service and a report job on a one-minute timer.

The app talks to monitoring tools through one adapter file per side. For this test, both adapters used Sentry's packages, so the only real difference was the DSN and the backend behind it.

Here's what I planted:

• Crashes: checkout throws a TypeError for an unknown coupon, which I'll call the coupon error, and a book page throws one for a missing book.
• Errors my code reports: out-of-stock checkouts, 503s from the price service, a recommendation call that rejects without a handler, and the report job failing every few runs.
• Storefront failures: the wishlist button crashes, and some API calls return 404, 500 or 502.
• Slow paths: the book page drags, search burns CPU, price lookups lag, and one cover image is missing.

A traffic script logged in as alice, bob and carol and shopped both through headless Chromium and straight against the API.

Three releases

The third release tested two different skills. A tool needs good grouping to report the new payment error sensibly, and it needs real request timing to explain a slowdown that never throws.

Packages and caveats

These conditions matter:

• GlitchTip ran on its hosted Free plan, with a 1,000-event monthly limit. My three releases used 1,097 events, mostly performance data.
• GlitchTip needed traceLifecycle: 'static' before it showed any performance data. Everything after phase 1's first run includes that setting.
• Seer could read my GitHub repository. GlitchTip has no built-in assistant, so the AI section isn't a head-to-head.

Setup and onboarding

Each tool accepted the storefront and the API under a single project, and the first errors landed within minutes. The differences came before the first project and after the first trace.

Sentry: Detected the repository and switched everything on

When I created the project, Sentry found my GitHub repository and proposed Express and Browser JavaScript as platforms. The onboarding page then offered products to collect:

The snippet arrives with my DSN filled in and every signal switched on, from errors and logs to metrics, tracing and profiling. It's a fast start, and worth trimming before your quotas fill.

GlitchTip: A plan, a team, then Sentry's snippet

GlitchTip wouldn't create a project until I had picked a plan:

The Free plan covers 1,000 events a month with unlimited projects and team members, and Small raises that to 100,000 for $15. The project form then required a team before it would save, which took one more small dialog.

The connect page is where GlitchTip's design shows:

It tells you to install @sentry/node, fills in the DSN and sets tracesSampleRate: 0.01 with a note that GlitchTip doesn't support sessions. Source maps also go through Sentry's tooling: sentry-cli uploaded my bundles once I pointed it at GlitchTip's URL with an auth token.

The trap came with performance. After a full traffic run with tracing at 100%, the Performance page was empty:

The SDK's debug log explained it: "Sending span envelope for trace … with 6 spans". Version 11 of Sentry's SDK streams spans in a newer format by default, and GlitchTip only reads classic transactions. Setting traceLifecycle: 'static' in Sentry.init switched the SDK back, and transactions appeared on the next request:

Two groups showed up: the report job at 927.92 ms and GET /books at 26.26 ms. GlitchTip's snippet doesn't mention this option, so anyone following it today gets errors and no performance data, and nothing tells them why.

Setup comparison

Verdict: Sentry. It worked as documented. GlitchTip's setup is quick, but its performance data silently depends on an SDK option you'd only find through a debug log.

Error capture

The first question is the simplest: did each tool record every failure I planted?

Sentry: 11 issues, every failure accounted for

After 1.0.0, Sentry showed 11 issues spanning the API, the storefront and the report job:

The promise rejection, "Recommendation engine timed out", has its own row. Storefront rows show a replay count, so you can tell which errors come with a recording.

GlitchTip: Every failure, spread over 24 issues

GlitchTip's list after the same release held 24 issues:

Every planted failure is there, including the recommendation timeout and the report job. The extra rows come from grouping, which has its own section below. Bulk actions across the top include Merge, which helps clean that up by hand.

The missing cover image never became an error in either tool.

Error capture comparison

Each tool got its own traffic run, so the row results matter more than the issue totals.

Verdict: Tie. The shared SDK caught the same failures for both. GlitchTip's higher issue count is a grouping result, not a capture one.

Debugging an error

Capture tells you something broke. The page around the error decides how quickly you learn why.

Sentry: Code, context and a trace across the stack

Sentry mapped the wishlist crash back to my source:

pages.js line 122 is highlighted beneath the comment that explains the bug.

What sets it apart is the link between a failed storefront request and the server error it caused:

The storefront's checkout failure lists the server's coupon TypeError as "1 other issue" in its trace, and the trace view follows the request from the click to the database query. The server issue also carries the shopper's session replay.

GlitchTip: The same code view, and nothing joining the two sides

GlitchTip's version of the wishlist crash looks familiar:

Line 122 is highlighted, with lines 117 to 127 around it, so source maps uploaded through sentry-cli work here too. The header above shows the shopper, the browser and a "copy for AI" link for pasting the event into an assistant.

Server errors include code as well, because the SDK sends context lines with every frame:

The coupon error points at server.js line 150 with the surrounding lines and my deliberate-bug comment. You get this without connecting a repository.

The breadcrumbs were noisier:

Of 13 breadcrumbs on this checkout error, only two came from the request: "checkout started" and "book found". The rest were startup lines and report job output from earlier minutes. The request body and headers below them were complete.

GlitchTip has no trace view, so the storefront's failed checkout and the server's coupon crash sit in the same list with nothing linking them.

Debugging comparison

Verdict: Sentry. Both show code on both sides. Only Sentry connects a storefront failure to the server error behind it.

GlitchTip left the failed checkout's two halves as unrelated rows, and Sentry's link lived in a preview box on the storefront error. When I sent the same checkout through Better Stack, the server exception led everywhere from one menu:

Its options cover the request's logs, its spans, its release and the replays of the session that triggered it. Opening the session lines both sides up:

Notice how the 30 frontend spans and 7 backend spans share one timeline, so a click and its server work read as a single story. In fairness, its browser tag is in beta, and my storefront frames stayed minified there.

Trace a failure from the click to the query

Error grouping

This is where sharing an SDK stopped mattering. Both tools received identical events, and they grouped them by different rules.

Sentry: Stack-based groups, with two duplicates later

Sentry groups by stack trace, which kept similar failures together. The new payment error in 1.2.0 was one issue with 13 events, though every message named a different amount.

Its weakness showed in the same release:

The new checkout code moved the server stack, so Sentry opened fresh issues for the coupon error and the out-of-stock error beside the originals.

GlitchTip: One issue per distinct message

GlitchTip groups by the error message. Any message that includes a variable becomes a new issue every time the variable changes, and my app has several of those.

The 1.2.0 payment error shows it most clearly:

Seven issues, one event each, for 21, 48, 35.99, 43.2, 39.99, 84 and 79.98 USD. It's the same line of code failing the same way.

The same rule split my out-of-stock error by book and by quantity, my order-tracking failures by query string, and my report job by run number, so "run #3 failed" and "run #6 failed" became separate issues.

Message grouping had one upside. The coupon and book errors kept a stable message through the 1.2.0 code change, so GlitchTip grew the existing issues without duplicating them:

The coupon error reached 32 events in its original row, where Sentry had opened a second one.

Error grouping comparison

Verdict: Sentry. Its duplicates came from one code change. GlitchTip split a single bug into seven rows on the first day it appeared, and kept splitting others every time a number changed.

GlitchTip turned one payment bug into seven rows, and Sentry duplicated two old bugs once their stack moved. The same release in Better Stack kept every one of them together:

The payment error is a single group of 10 exceptions despite a different amount in each message, and the code around server.js line 173 sits right on the page. Notice the deliberate-bug comment: the cause is readable without leaving the error. The coupon error also stayed one error from 1.0.0 to 1.2.0, so the list matched the number of real bugs.

Keep one bug in one row

Real user monitoring and session replay

With replay, you can watch what led a shopper to a failure. Real user monitoring records page speed as shoppers felt it.

Sentry: Replays and a vitals score

Every storefront session was recorded with text masked, and each replay opened on an AI summary:

The summary's steps match the session, and the wishlist failure is marked. The replay's Network tab was also the only place the missing cover image turned up, as a 404.

Sentry scored the storefront 90 on its Web Vitals dashboard. Hash routing meant every page was named /, so per-page numbers weren't useful for my app.

GlitchTip: Breadcrumbs only

GlitchTip doesn't support session replay. Its browser errors carry breadcrumbs for clicks, navigations and fetch calls, which is the only view of what the shopper did.

I also expected browser page-load timings, since the browser adapter had tracing turned on. None arrived: every transaction group on the Performance page came from the server.

Real user monitoring comparison

Verdict: Sentry. GlitchTip gave me neither replays nor browser timings, so this one wasn't close.

Release tracking and regressions

For 1.1.0, I closed the coupon error in both tools as fixed in the next release, then shipped it unfixed.

Sentry: Every place says Regressed

Sentry's Resolve menu offers the next release, any release, the current release or a commit. After 1.1.0, the coupon row in the list carried a label:

"Regressed" sits under the trend graph, and the release page has a Regressed tab listing exactly this issue. The activity feed recorded the event too.

GlitchTip: The same option, then silence

GlitchTip offers the same choice:

I chose "Resolve in next release". The first coupon error from 1.1.0 reopened the issue without my help:

The latest event is tagged monitoring-lab@1.1.0, and the status reads "Unresolved". Nothing says it came back: there's no regression label, and the issue has no history beyond an empty Comments tab. In the list, it looked like every other row.

The release itself didn't help either:

"Release files for monitoring-lab@1.1.0 (12)" lists my uploaded bundles and nothing else. There are no errors, new issues or regressions per release.

Release tracking comparison

Verdict: Sentry. GlitchTip does the reopening right and then tells you nothing about it.

GlitchTip reopened the coupon error without a word, and Sentry spread its signal across a label, a tab and a feed. In Better Stack, the comeback was the first thing in the list:

One red "Reoccurred" status marks the only bug that returned. Its page shows why:

Notice the reoccurrence logged above my resolve, the history GlitchTip doesn't keep. Sentry's per-release Regressed tab is one view it still has that Better Stack doesn't.

See a returning bug before you open it

Performance monitoring

Release 1.2.0 added a slow SELECT book for checkout query. Checkout went from milliseconds to seconds and threw nothing.

Sentry: The trace names the query

One slow 1.2.0 checkout in Sentry was enough:

Of that 2.26 s request, 1.79 s went to the book query and 459 ms to the card charge that failed. In Trace Explorer, checkout's p95 moved from 5.29 ms and 3.63 ms on the first two releases to 5.93 s on 1.2.0, which pinned the slowdown to the deploy.

GlitchTip: Route averages and a lagging breakdown

Once transactions flowed, GlitchTip listed every server route by average duration. After 1.2.0, checkout had climbed:

POST /checkout averaged 752.27 ms, up from 3.27 ms after the first release. That's a clear signal, but the average blends all three releases, and the page only filters by environment, not release.

A route's page shows the breakdown by span:

It splits time between handler, middleware and database calls, and lists each span with count, average and p95. Here it covers 165 spans against 216 transactions, and SELECT book for checkout shows a 0.58 ms p95. The slow 1.2.0 queries hadn't reached the breakdown when I checked, so it pointed away from the real cause.

For the first hours, the same panel had said "No span data available yet". There's no list of individual transactions and no trace view, so you can't open one slow checkout to see what happened in it.

The 1.2.0 payment error did leave a clue in its breadcrumbs: "checkout started" and "book found" were 1.9 s apart, next to my app's own "slow query" warning.

Performance comparison

Verdict: Sentry. GlitchTip told me checkout had slowed down, on average, at some point. Sentry told me which release, which request and which query.

GlitchTip could only report a blended average, and Sentry's view of the app's own slow-query warnings lived on another tab. In Better Stack, I started from the payment error and opened one failing 1.2.0 checkout:

The request's timing survived intact. Of 2.19 s in total, the book query used 1.53 s and the card charge 660 ms. The logs for the same request were a click away:

Notice the slow-query warning a line above the checkout failure, so the measurement and the explanation arrive together. The Service column is blank, because the SDK I used sets no service name.

Open the request behind every slow average

Logs and events

Both tools accepted structured logs from the SDK.

Sentry: Logs per trace

Sentry kept a searchable Logs explorer, and each trace has a Logs tab:

For one failed checkout, the storefront's and the server's log lines appear in order, each beside its error.

GlitchTip: A plain list

GlitchTip's Logs page received 233 lines after one run:

Each line has a timestamp, a level and a message, with search and a level filter. The Service filter stayed empty, and logs weren't linked to errors or requests. On the hosted plans, ten log lines count as one event, so logging is cheap.

Logs comparison

Verdict: Sentry. GlitchTip stores logs cheaply, but you can't get from an error to its logs.

Uptime and alerts

GlitchTip has an Uptime Monitors section in its main navigation, and its pricing counts ten uptime checks as one event. Sentry's plans include one uptime monitor and one cron monitor, with more billed per monitor.

My app ran on localhost, so I didn't test uptime in either tool, or alert delivery.

Verdict: Not compared.

AI-assisted debugging

There's no fair matchup here. Sentry has a built-in assistant, which I tested with my repository connected. GlitchTip only offers a "copy for AI" link on each event.

Sentry: Seer nails the code bugs, misses the slowdown

Seer needed roughly 15 seconds to explain the coupon error:

It was correct, down to the line and the two coupons the app actually knows. On 1.2.0, it also found the counter that fails every fifth payment.

Asked what changed in 1.2.0, Seer Agent got the latency numbers right and blamed the payment step for the slowdown, though the trace shows the book query costing more. A follow-up didn't change its answer.

GlitchTip: Copy for AI

The "copy for AI" link copies an event so you can paste it into an assistant you already use. I didn't test it.

AI comparison

Verdict: Not compared. Seer is the only built-in AI here, and it was half right on the hard question.

GlitchTip leaves the diagnosis to whichever assistant you paste into, and Seer Agent pinned the slowdown on the wrong step even with my code. Better Stack's AI SRE got the identical question and no repository:

It saw that only the book query had slowed while other statements held steady, which ruled out the database server. It then treated the payment failures as a second, separate cause:

Notice the card charge span failing 10 of 48 calls on 1.2.0, tied to the new payment error. The run cost $0.49 and roughly four minutes, slower than Seer, and it was the only assistant in my tests to get both causes right.

Put AI SRE on your next bad release

Pricing

Sentry sells separate quotas for errors, spans, replays and logs. GlitchTip counts everything as events, at a much lower price per event, and its code is open source for anyone who wants to run it themselves.

These numbers come from each vendor's pricing page on October 27, 2026. Check them again before you commit.

Free plans and trials

My test used 1,097 events on GlitchTip's Free plan, and GlitchTip kept accepting them with a warning banner:

The banner reads "You're at 110% of your event limit. Upgrade before throttling kicks in." Most of the count came from performance transactions.

Entry-level paid plans

GlitchTip's larger plans are Medium at $50 a month for 500,000 events and Large at $250 for 3 million. Sentry Business costs $89 a month, or $80 billed annually.

What costs extra

Comparing the actual cost

GlitchTip is cheaper by a wide margin. Its Small plan costs about half of Sentry Team and covers twice as many events, with errors, transactions and logs drawing from one pool.

Sentry's higher price pays for depth that GlitchTip doesn't have: replay, real traces and profiling. Those were the features that won Sentry the debugging and performance sections. If you only want a list of exceptions with source code, you'd be paying Sentry for capabilities you won't open.

GlitchTip's own costs show up as time. Message-based grouping means merging duplicates by hand, and its release and performance views won't tell you much after a bad deploy. If you want errors, logs and on-call in one product instead, see how an all-in-one platform compares with Sentry.

Verdict: GlitchTip. It's the cheapest way to get the error-tracking half of what Sentry does, with Sentry's own SDK.

Full feature comparison

Here's every result from my test in one place.

Which should you choose?

Decide whether you need a list of exceptions or an explanation of them.

Choose Sentry if you debug across the browser and the server

Sentry won every section where the answer depended on context the SDK collected. It joined each storefront failure to its server error, marked the returning coupon bug in three places, kept one issue for the payment error and named the slow query from a single trace.

Its replays showed what shoppers did, and Seer got both code bugs right with my repository. The costs are a higher bill, two duplicate issues after a code change, and an assistant that misread the slowdown.

For a lighter commercial alternative, our Sentry vs Honeybadger comparison looks at a tool that bundles logs and uptime instead of replay. And if grouping is your main concern, our Sentry vs BugSnag comparison tests different defaults on the same app.

Choose GlitchTip if you want exceptions with code, cheaply

GlitchTip makes sense for a small team, a side project or anyone who wants to self-host. It runs on Sentry's SDK, caught every failure I planted, showed source code on both sides and reopened the returning bug on time, for $15 a month or nothing on your own server.

Expect to work around it. Its message-based grouping split one payment bug into seven issues, it keeps no history of a regression, its releases list only files, and its performance page reports averages that blend every release. You'll also need to know about traceLifecycle: 'static', or you'll see no performance data at all.

Final thoughts

Same SDK, same events, two very different answers. The SDK decides what's collected, but the backend decides whether seven payment failures are one bug or seven, and whether a returning bug says anything when it comes back.

GlitchTip is a fair deal for what it is: a cheap, open way to keep exceptions and their code in one place. Sentry is what you pay for when the exception isn't the whole story.

If your hardest bugs come with a stack trace, GlitchTip will do. If they show up as "checkout feels slow since Tuesday", you'll want the backend that keeps the trace.

Got an article suggestion? Let us know

Explore more

Better Stack vs GlitchTip: A Complete Comparison for 2026

Comparing Better Stack and GlitchTip on error tracking, uptime monitoring, pricing, self-hosting, and observability depth to help you choose the right tool for your stack.

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

A hands-on Sentry vs Honeybadger comparison on the same app, covering error capture, debugging, grouping, release tracking, finding a slowdown with traces or logs, session replay, AI and pricing.

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

A hands-on Sentry vs Raygun comparison on the same app, covering error capture, debugging, grouping, real user monitoring, release tracking, APM, AI and pricing, including a bad release Raygun called faster.

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