# 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.
[ad-logs]
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.
| Area | Better in my test | Why |
|---|---|---|
| Setup | **Sentry** | GlitchTip sent no performance data until I changed an SDK option its setup page skips |
| Error capture | Tie | Both caught every planted failure, including the promise rejection and the job |
| Debugging | **Sentry** | One trace from the browser click to the server crash; GlitchTip has no trace view |
| Error grouping | **Sentry** | GlitchTip groups by message, so one payment bug became seven issues |
| Real user monitoring and session replay | **Sentry** | GlitchTip offers no replay, and no browser transactions arrived |
| Release tracking | **Sentry** | A Regressed label and tab; GlitchTip reopened silently and lists only files per release |
| Performance | **Sentry** | Traces with the slow query named; GlitchTip shows averages across all releases |
| Logs and events | **Sentry** | Logs tied to each trace; GlitchTip has a plain searchable list |
| Uptime and alerts | Not compared | Both list uptime monitoring; neither was tested |
| AI-assisted debugging | Not compared | Only Sentry has an assistant, which I ran against my repository; GlitchTip copies events out |
| Starting price | **GlitchTip** | $15 a month for 100,000 events of any kind, or free to self-host |
## 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
| Release | Purpose |
|---|---|
| 1.0.0 | Baseline: setup, browser and server capture, source maps, context, tracing, logs |
| 1.1.0 | I marked the coupon error fixed and released it unfixed |
| 1.2.0 | The bad deploy: a slower checkout query, and a payment failure on one charge in five |
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
| Tool | Packages used |
|---|---|
| Sentry | `@sentry/node`, `@sentry/browser` and `@sentry/profiling-node`, version 11.8.0 |
| GlitchTip | `@sentry/node` and `@sentry/browser` 11.8.0 with a GlitchTip DSN; replay and profiling off |
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
| Capability | Sentry | GlitchTip |
|---|---|---|
| Browser and server in one project | ✔: one DSN | ✔: one DSN |
| SDK | ✔: its own | ✔: Sentry's SDK |
| Plan choice before the first project | ✘: not required | Required, Free available |
| Team required per project | ✘: not required | ✔: yes |
| Source map upload | ✔: `sentry-cli` | ✔: `sentry-cli` with `--url` |
| Performance with the current SDK and default snippet | ✔: works | ✘: empty until `traceLifecycle: 'static'` |
**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
| Test | Sentry | GlitchTip |
|---|---|---|
| Browser exceptions | ✔: caught | ✔: caught |
| API exceptions | ✔: caught | ✔: caught |
| Unhandled rejection | ✔: caught | ✔: caught |
| Report job failures | ✔: caught | ✔: caught |
| Missing cover image | Replay Network tab only | ✘: not reported |
| Issues after release 1.0.0 | 11 | 24 |
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
| Capability | Sentry | GlitchTip |
|---|---|---|
| Browser source maps | ✔: shown with code | ✔: shown with code |
| Server source lines | ✔: with a GitHub link | ✔: from SDK context lines |
| User and request context | ✔: shown | ✔: shown, with headers |
| Breadcrumbs scoped to the request | ✔: yes | ✘: mixed with earlier console lines |
| Browser to server link | ✔: shared trace | ✘: no trace view |
| Replay on a server error | ✔: yes | ✘: no replay |
| Copy an event for an AI | Not tested | "copy for AI" link, not tested |
**Verdict: Sentry.** Both show code on both sides. Only Sentry connects a storefront failure to the server error behind it.
[summary]
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](https://betterstack.com/tracing)**
[/summary]
## 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
| Test | Sentry | GlitchTip |
|---|---|---|
| Payment error with changing amounts | ✔: one issue | ✘: seven issues |
| Stock error for different books | ✔: grouped as one | ✘: one issue per book and quantity |
| Report job across runs | ✔: one issue | ✘: split by run number |
| Coupon error once 1.2.0 moved its code | ✘: new duplicate | ✔: kept in place |
| Correction tools | Fingerprint rules | Merge, not tested |
**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.
[summary]
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](https://betterstack.com/error-tracking)**
[/summary]
## 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
| Capability | Sentry | GlitchTip |
|---|---|---|
| Session replay | ✔: every session in my test | ✘: not supported |
| AI replay summary | ✔: yes | ✘: not offered |
| Browser page-load timing | ✔: Web Vitals dashboard | ✘: none arrived |
| Click and fetch trail on errors | ✔: automatic | ✔: automatic |
**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
| Capability | Sentry | GlitchTip |
|---|---|---|
| Releases from the SDK | ✔: yes | ✔: yes |
| Resolve in the next release | ✔: yes, plus a release or a commit | ✔: yes |
| Reopen when the bug returns | ✔: automatically | ✔: automatically |
| Regression label | ✔: Regressed | ✘: plain Unresolved |
| Issue history | ✔: activity feed | ✘: none |
| Errors per release | ✔: release page tabs | ✘: files only |
**Verdict: Sentry.** GlitchTip does the reopening right and then tells you nothing about it.
[summary]
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](https://betterstack.com/error-tracking)**
[/summary]
## 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
| Capability | Sentry | GlitchTip |
|---|---|---|
| Request traces | ✔: browser to database | ✘: no trace view |
| Individual slow requests | ✔: open any trace | ✘: averages only |
| The 1.2.0 book query | ✔: a 1.79 s span | ✘: not in the span breakdown when checked |
| Latency by release | ✔: p95 per release | ✘: no release filter |
| Route ranking by duration | ✔: yes | ✔: average per route |
| Profiling | Included, unhelpful for a waiting query | ✘: not supported |
**Verdict: Sentry.** GlitchTip told me checkout had slowed down, on average, at some point. Sentry told me which release, which request and which query.
[summary]
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](https://betterstack.com/log-management)**
[/summary]
## 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
| Capability | Sentry | GlitchTip |
|---|---|---|
| Log storage | ✔: Logs explorer | ✔: Logs list |
| Logs for one request | ✔: on the trace | ✘: not linked |
| Search and level filter | ✔: yes | ✔: yes |
| Billing | 5 GB included, then $0.50 per GB | 10 lines count as 1 event |
**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
| Capability | Sentry | GlitchTip |
|---|---|---|
| Assistant inside the product | ✔: Seer, with my repository | ✘: not offered |
| Coupon and payment bugs | ✔: both explained correctly | Not tested |
| Why 1.2.0 got slower | ✘: pointed at payments, not the query | Not tested |
| Copy an event for an outside AI | Not tested | "copy for AI", not tested |
**Verdict: Not compared.** Seer is the only built-in AI here, and it was half right on the hard question.
[summary]
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](https://betterstack.com/ai-sre)**
[/summary]
## 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
| Item | Sentry Developer | GlitchTip Free |
|---|---|---|
| Price | Free | Free |
| Seats | 1 | Unlimited team members |
| Volume | 5,000 errors, 5M spans and 50 replays | 1,000 events, errors and transactions combined |
| Logs | 5 GB | 10 lines count as 1 event |
| Retention | 30-day lookback | 30 days |
| Over the limit | Not covered in this snapshot | Throttles gradually, blocks at twice the limit |
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
| Item | Sentry Team | GlitchTip Small |
|---|---|---|
| Monthly price | $29 a month, or $26 billed annually | $15 a month, with an annual discount |
| Seats | Unlimited | Unlimited |
| Volume | 50,000 errors, 5M spans and 50 replays | 100,000 events |
| Retention | Up to 90-day lookback | 90 days |
| Replay and profiling | ✔: included quotas | ✘: not supported |
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
| Need | Sentry | GlitchTip |
|---|---|---|
| More volume | Pay-as-you-go budget | On-demand events from $0.17 per 1,000 |
| More logs | $0.50 per GB over 5 GB | Counted as events, 10 lines each |
| Profiling | From $0.25 per UI profiling hour | ✘: not supported |
| AI | Seer sold separately, price not listed | ✘: not offered |
| Self-hosting | Not covered in this test | ✔: open source, free to run |
### 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](https://betterstack.com/community/comparisons/better-stack-vs-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.
| Feature | Sentry | GlitchTip |
|---|---|---|
| SDK | ✔: its own | ✔: Sentry's |
| Performance with the default snippet and SDK 11 | ✔: works | ✘: needs `traceLifecycle: 'static'` |
| Promise rejection with no handler | ✔: captured | ✔: captured |
| Browser and server source code | ✔: both | ✔: both |
| Breadcrumbs scoped to the request | ✔: yes | ✘: mixed with earlier lines |
| Browser to server link | ✔: shared trace | ✘: not offered |
| Grouping | Stack-based | Message-based |
| Payment error with changing amounts | ✔: one issue | ✘: seven issues |
| Duplicates when code moved | ✘: two | ✔: none |
| Session replay | ✔: with AI summaries | ✘: not supported |
| Browser page-load timing | ✔: Web Vitals | ✘: none arrived |
| Resolve in the next release | ✔: yes | ✔: yes |
| Regression label | ✔: Regressed | ✘: not offered |
| Errors per release | ✔: yes | ✘: files only |
| Request traces | ✔: browser to database | ✘: averages only |
| Latency by release | ✔: yes | ✘: no release filter |
| Logs linked to requests | ✔: yes | ✘: no |
| Uptime monitoring | 1 monitor, not tested | Listed, not tested |
| Built-in AI | ✔: Seer, tested | ✘: copy for AI only |
| Free plan | ✔: 1 user, 5,000 errors | ✔: unlimited members, 1,000 events |
| Entry price | $26 to $29 a month | $15 a month |
| Self-hosting | Not tested | Open source |
## 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](https://betterstack.com/community/comparisons/sentry-vs-honeybadger/) looks at a tool that bundles logs and uptime instead of replay. And if grouping is your main concern, our [Sentry vs BugSnag comparison](https://betterstack.com/community/comparisons/sentry-vs-bugsnag/) 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.**