AppSignal vs GlitchTip: A Hands-On Error Tracking Comparison for 2026

The cheaper of these two tools caught a failure the other one never reported. In my test app, a recommendations call rejected a promise that no code handled. GlitchTip filed it as an issue on the first run. AppSignal logged the request at a 0% error rate, and the rejection only turned up in its log view because the app happened to write a line about it.

The positions swapped once the faulty release shipped. AppSignal's checkout page listed a mean response time per deploy: 2 ms on the two earlier releases, then 4.59 s on the bad one. GlitchTip folded all three releases into one checkout average of 752.27 ms, and nothing on the page let me pull the new release out of it.

AppSignal is an application performance monitor with error tracking built in, alongside traces, logs, host metrics, anomaly triggers and heartbeat monitors, all billed by request volume. It runs its own agent and SDKs.

GlitchTip takes a smaller brief. It's an open-source error tracker that speaks the Sentry SDK protocol, adds basic performance averages, logs and uptime checks, and sells hosted plans by event count, or you can run it on your own servers for free.

My testing ran through the last week of October 2026, on one purpose-built broken shop. The sections ahead cover setup, error capture, debugging, grouping, real user monitoring, releases and regressions, performance, logs, monitoring and alerts, AI and pricing.

AppSignal vs GlitchTip: Results at a glance

These verdicts come from my own Express and Vite setup. A CommonJS app, an older Sentry SDK or connected alert channels might move one or two of these calls.

How I tested AppSignal and GlitchTip

My test subject is a deliberately faulty bookstore. Its Express API stores books and orders in SQLite, its Vite storefront routes by URL hash, a fake price service sits beside it, and a scheduled job assembles a daily sales report. A headless browser played the shoppers, and both tools got identical failures from identical code.

What I seeded into it:

• Storefront crashes: a "wishlist" click that dereferences a null object, plus API failures that the storefront reports on its own.
• API crashes: an unrecognized coupon at checkout, a book lookup for a record that isn't there, and stock running out.
• An unreliable upstream: the price service sometimes returns a 503.
• Async failures: a recommendations request whose promise rejects with no handler, and a report job that throws.
• A slowdown and a fresh bug: both held back for the last of three versions.

The releases

Release 1.2.0 carried the most weight. It put a slowdown and a brand-new error on the same request, so a tool had to tell you both that something broke and why that request got slow.

SDKs and test limitations

• Counts: each tool saw its own traffic runs, so event and error counts don't compare one to one.
• Localhost: uptime checks in both tools run from the vendor's side and couldn't reach the app, so neither was tested.
• A Linux server for one run: AppSignal's host metrics only appear on Linux, so I ran 1.2.0 a second time on my Ubuntu server to see them.
• Adapter fixes: after AppSignal's first run, I fixed my own adapter so custom spans and handled errors joined the request. I left unhandled rejections to each SDK, so capture results reflect the defaults.
• GlitchTip's free limit: the test used 1,097 events against a 1,000-event plan, which may have affected the last performance data.
• No alert channels: I didn't connect email, Slack or any other notifier to either tool.

Setup and onboarding

Setup decides how soon a tool tells you something true about your app. Both tools got running inside an hour, and each had one trap a team could easily miss.

AppSignal: A clear wizard with a CommonJS assumption

AppSignal opens with a language picker that also tells you what each option covers:

Node.js is "Full APM", while plain JavaScript is "Errors only". The wizard then walks through the npm install, a framework choice, the Express error handler and a config file:

Every step assumes CommonJS and node --require. My app uses ES modules, so I had to register AppSignal's import hook myself, or Express would have gone untraced. The wizard never mentions that path.

My first attempt ended on "Uh-oh! No data received :(", which was my own fault: a placeholder key left in the environment file. The failure page pointed to appsignal.log and a diagnose command, and once the key was fixed, data arrived within about a minute:

The deploy marker on the charts came for free. Setting revision in the config created the deploy, with no separate API call.

GlitchTip: A plan, a team, then a silent gap

GlitchTip sends you to its plans before you can create anything:

I picked Free, which allows 1,000 events a month. The project form then wouldn't save until I created a team with the + button next to the team field:

The connect page is the Sentry Node.js snippet with your DSN filled in:

The snippet switches autoSessionTracking off, with a comment explaining that GlitchTip has no sessions. For source maps, you point Sentry's own sentry-cli at GlitchTip's URL.

The trap was performance. The snippet installs the current Sentry SDK, version 11, which streams spans by default, and GlitchTip only reads the older transaction events. After a full traffic run with sampling at 100%, this is what Performance showed:

Nothing on the page explains the empty state. The SDK's debug log said "Sending span envelope", and the fix was SDK 11's traceLifecycle: 'static' option, which the connect page doesn't mention.

Setup comparison

Verdict: Mixed. AppSignal's wizard is clearer, but an ESM app needs a step it doesn't document. GlitchTip's errors work at once, while its performance page stays empty until you find a setting the setup page leaves out.

Error capture

Capture is the first test of any error tracker: did it see every failure, and did it count each one once? These two tools disagreed on both.

AppSignal: Every crash but the one nobody handled

After the first run, AppSignal's error list held 11 issues:

The server crashes, the price service's 503s, the report job and the browser crash all arrived. The new Browser SDK also reports failed fetches as their own HTTPError, which lands next to the storefront's own ApiError for the same call, so one failure can count twice.

The unhandled rejection never became an error. Its route showed 7 requests at a 0% error rate, and the only trace of it was a log line:

The message "Recommendation engine timed out for user anonymous" is there because my app logs rejections. An app that doesn't would see nothing.

GlitchTip: Everything, including the quiet failure

GlitchTip's first run produced 24 issues:

Every planted failure is in the list, the unhandled rejection included, with 6 events. The sales report error arrived about a minute after the others. The issue count is high for a different reason, which the grouping section covers.

Capture comparison

Verdict: GlitchTip. It caught every planted failure. AppSignal missed an unhandled rejection, and in a Node app that's the failure most likely to happen with no code written to report it.

Debugging an error

An error page earns its place by getting you to the bad line and showing what led there. Each tool did one half of that well.

AppSignal: Strong browser context, blind server frames

On server errors, AppSignal couldn't read my app's own frames:

Hovering the warning icon on the server.js frame gives a parse error about an invalid digit. AppSignal didn't parse the file:// frame format that ES modules produce, so no backend code appears, and there's no toggle to hide the framework frames around it.

The request side is better. The error page carries the JSON body and the release it first appeared in:

The deploy box names the release, which matters later. The "No related log lines found" banner stays until you link logs to traces.

Browser errors are where AppSignal shines. Source maps resolved the wishlist crash to its original file:

The frame points at src/pages.js:122:13, where the code view marks the wishlist.items.push call that crashed. The breadcrumbs above the error read like a transcript:

The click row even names the button and its screen position, followed by my app's own note and the crash. On the server, the Node SDK has no breadcrumbs API, so my adapter stored them as custom data that shows as raw JSON.

GlitchTip: Source lines everywhere, a noisy trail

GlitchTip showed the failing server line straight from the SDK:

Lines 145 to 155 are visible, the planted-bug comment included, with no repository connected. The Sentry SDK sends these context lines itself.

Browser source maps worked too, through the debug IDs sentry-cli injects:

GlitchTip lands on line 122 of ../../src/pages.js as well, with the planted-bug comment in view.

The server breadcrumbs were less useful:

Of 13 breadcrumbs on the coupon error, only "checkout started" and "book found" belonged to that request. The rest were startup and report-job lines from other minutes. This may come from my console capture settings, but it's what the page showed. Below the trail, the Request section has the body and every header.

Debugging comparison

Verdict: Mixed. GlitchTip got you to the failing server line, which AppSignal couldn't do with ES modules. AppSignal's browser trail and request context were cleaner, so the winner depends on which side of your app breaks more.

Error grouping

Grouping decides whether a bad release shows up as one problem or a page of them. AppSignal groups by error class and the route it happened on. GlitchTip groups by message, and that choice decided this section.

AppSignal: One issue per bug and route

With my adapter fixed, AppSignal kept each bug in one issue per route:

The out-of-stock error moved under POST /checkout, and the other groups kept growing in place. The browser's ApiError splits by route template, so /orders and /books/:id are separate issues, which is reasonable.

On 1.2.0, the payment error arrived as a single issue with every amount inside it:

The message includes "31.95 USD", and other events carried other amounts, yet it's all one issue. That's what you want from a new bug on a busy code path.

GlitchTip: A new issue for every new value

Because GlitchTip groups by message, any value inside the message makes a new issue. The payment error split into seven:

Each amount, from 35.99 to 84 USD, has its own row with one event. Pulling them back together is manual work through the Merge action, which I left untried.

The same thing happened to the report job, whose message includes its run number:

"run #3" and "run #6" are separate issues. Six different query strings on one tracking URL also made six issues in the first run. One thing went better than in Sentry, which uses the same SDK: the old bugs didn't split again when 1.2.0 changed the code around them.

Grouping comparison

Verdict: AppSignal. It kept every planted bug together, values and all. GlitchTip's grouping is fine for messages that never change, but most real messages carry an ID, an amount or a count.

GlitchTip turned one payment bug into seven single-event issues, and AppSignal kept it whole but couldn't show its server code. I also tested the same release in Better Stack, which received it through the same Sentry SDK that GlitchTip uses and kept the payment error as one group of 10 exceptions:

The amounts differ in every message, yet there's one group, with the code around server.js:173 on the page. You get GlitchTip's SDK compatibility and source lines without the hand-merging.

Group errors without merging them by hand

Real user monitoring and session replay

Real user monitoring shows what a release did to people's page loads, and replay shows what one person saw. Neither tool records sessions, so this section is about the browser data each one keeps.

AppSignal: Web vitals as raw metrics

AppSignal's Browser SDK collects Core Web Vitals, but there's no page for them. You find them in the metric picker when you build a dashboard chart:

The five metrics cover CLS, FCP, INP, LCP and TTFB. A chart of one can split by page and release:

The page_url and app_version tags are the useful part, since they let you compare a page across releases. The peaks near 6,000 ms reflect headless Chromium and my app's planted delays more than a real visitor.

GlitchTip: Browser context on errors only

GlitchTip keeps browser details on each error event:

The header shows the user, browser and OS, with release and environment tags. GlitchTip recorded no pageload or navigation transactions from the storefront, even with browser tracing on and the static lifecycle set, so there's no picture of load times.

RUM comparison

Verdict: AppSignal, narrowly. It kept the numbers, even if you have to build the chart yourself. GlitchTip kept browser context on errors and nothing about page performance.

Release tracking and regressions

Release tracking should tell you two things after a deploy: what's new, and which fixed bug came back. I marked the coupon bug fixed before 1.1.0 and shipped it again unchanged.

AppSignal: Reopened silently, with a deploy table

AppSignal has three states, and its dropdown spells out the reopen rule:

The note says a triggered notification reopens a closed incident. The coupon error's alerting was "First in deploy", so the 1.1.0 recurrence did reopen it:

Open again, yet nothing marks it as a regression, and its deploy box still names 1.0.0 as the origin. Its Logbook missed the reopen too:

The only entry is my own close. A teammate opening this issue wouldn't know it came back by itself.

The error list does help, because its default filter shows only errors seen in the latest revision:

The "In selection" column counts 1.1.0 events and "Total" counts all time, so the coupon error shows 5 of 30. The Deploys page adds an error rate per release:

Release 1.1.0 ran at 876.4 errors an hour against 273.33 for 1.0.0, though the rows don't open a detail page. On 1.2.0, the new payment error looked like any other row:

It sits fourth by last seen, with no "new" badge. "In selection" equal to "Total" is the only hint.

GlitchTip: A better resolve option, a thinner release page

GlitchTip's status menu has the option AppSignal lacks:

I chose "Resolve in next release" for the coupon error. When 1.1.0 brought it back, it reopened:

The header reads "Unresolved" and the latest event carries the 1.1.0 release tag. There's no regressed label, no activity history, and the Comments tab is empty.

The release page didn't add much:

It lists the 12 uploaded bundle files and nothing about errors. On 1.2.0, the issue list was the only place to look:

The new payment rows stand out only because they're a few minutes old. The old bugs grew in place, so at least the list didn't fill with duplicates.

Release comparison

Verdict: Mixed. Both reopened the bug and neither said so. GlitchTip's resolve option is the better workflow, while AppSignal's revision filter and Deploys page are the only real release views here.

Both tools reopened the returning bug and left it looking like every other row, with nothing in either history. I also tested the same 1.1.0 release in Better Stack, which marked the coupon error with a red "Reoccurred" status right in the error list:

Notice that only the coupon row changed, and the error page's activity feed records the reopen next to my resolve. Better Stack has no deploy step or resolve-on-release option, but a regression is visible before you open anything.

See which fixed bugs came back

Performance monitoring

A bad deploy rarely announces itself as an error. Performance data is what shows a request getting slower, and 1.2.0 made checkout slower by three orders of magnitude.

AppSignal: The bad deploy in one table

The checkout action page compares the last deploys side by side:

The mean went from 2 ms on 1.0.0 and 1.1.0 to 4.59 s on 1.2.0. That's the clearest before-and-after view of the slowdown in this test.

A slow checkout trace from 1.2.0 then showed where the time went:

The book lookup took 3.06 s, the card charge 3.3 s with an error and a retry, and the insert 1.33 s. The breakdown credits 4.39 s to SQLite.

There's a catch. The trace attached to a failed checkout kept only its root span:

The error took 3.34 s, and the breakdown calls all of it "Other". To explain the payment error's slowness, you have to find a successful slow trace instead.

The Slow queries page re-ranked itself after the release:

The book lookup rose to 67.6% of query impact, up from 22.02% in the first run, with a 1.03 s mean. AppSignal also ranked outgoing HTTP calls on their own page with no code from me:

The price service shows as GET localhost at 3.21 s mean, tied to the route that calls it.

GlitchTip: Averages per route

Once I set the static lifecycle, GlitchTip began listing transactions:

Groups are routes, ranked by average duration. A group page shows only aggregates:

Checkout averaged 3.27 ms across 82 transactions, and its span breakdown was still empty. With no per-request list and no waterfall, a single slow checkout stays out of reach.

After 1.2.0, checkout climbed the list:

Its average rose to 752.27 ms, which blends all three releases. Performance has no release filter, so you can't set 1.2.0 against 1.1.0. The span breakdown filled in later:

It shows 165 spans against 216 transactions, with the book lookup at 0.58 ms at p95. That looks like the earlier, fast requests only. The slow 1.2.0 spans may have arrived later, or been dropped near the plan limit.

Performance comparison

Verdict: AppSignal. It showed the slowdown, its cause and the release that brought it. GlitchTip showed that checkout got slower on average and stopped there.

AppSignal's trace for the failing checkout dropped its child spans, and GlitchTip has no trace to open at all. I also tested the same failing request in Better Stack, and opening the payment error's spans showed that request whole:

The book lookup takes 1.53 s of the 2.19 s request and the card charge 660 ms, both on the request that threw. You get the cause and the error on one screen, with no hunt for a healthy slow trace.

Trace the request behind each error

Logs and events

A log line is often the only record of a failure nobody reported, like the rejection earlier. Both tools accept logs from the same SDK that sends errors.

AppSignal: Searchable lines with attributes

AppSignal's logger worked with no extra setup:

Each line has severity, host and group, and live tail is built in. The detail panel for a line shows its attributes and offers "Show in context", "Open time detective" and "Create a metric".

Time Detective is the view I'd use in an incident. It freezes one minute across errors, performance and logs:

At 10:33 on 1.2.0, checkout ran at 4.76 s mean and 7.23 s at p90, next to a book page at 1 ms. The arrows step a minute forward or back.

GlitchTip: A plain list

GlitchTip stored 233 log lines from the first run:

You get a timestamp, a level and the message, with search, Level and Service filters. Clicking a line opened no detail panel. The "metric" lines are my adapter's doing, since GlitchTip has no custom metrics.

Logs comparison

Verdict: AppSignal. Its logs connect to the rest of the app, and Time Detective puts a bad minute on one screen. GlitchTip keeps the lines and little else.

AppSignal's error pages said "No related log lines found" until logs were tied to traces, and GlitchTip's lines don't open at all. I also tested the same checkout failure in Better Stack, where "View logs" on the exception opened Live tail filtered to that request's trace ID:

The failed checkout line sits beside the slow-query warning from the same request, so the log already hints at the cause. It worked from the error page, with no extra wiring.

Open the logs behind any error

Uptime, monitoring and alerts

Monitoring covers what happens outside a request: hosts, scheduled jobs and the alerts that wake someone up. AppSignal treats this as core. GlitchTip offers uptime checks, which I couldn't test on localhost.

AppSignal: Host metrics and heartbeats worked, the trigger didn't fire

Before 1.2.0, I set a Slow actions trigger at a 1,000 ms mean:

The form picks a namespace, here web, with no option for a single route. When checkout hit 4.59 s, the trigger raised nothing:

Fast GET requests kept the web namespace's mean under the threshold. A lower threshold would have fired on the first run's planted spikes too, so the limit here is per-namespace triggers more than my number.

Host metrics need no setup on Linux. Once the app ran on my Ubuntu server, the host appeared:

Load, memory and disk usage came straight from the agent. I also wrapped the app in appsignal-run with a two-minute heartbeat, then stopped it:

The monitor turned red with "Missed" about two to three minutes later. The heartbeat monitor has to exist before the wrapper's beats appear, and the CLI gives no warning about that.

GlitchTip: Uptime included, not tested

GlitchTip's usage page counts uptime checks alongside errors, transactions and logs, and the product includes uptime monitors and alerts. I tested neither, because the checks couldn't reach a localhost app and I didn't connect a notifier.

Monitoring comparison

Verdict: Not compared. I didn't deliver an alert from either tool. AppSignal's host and heartbeat monitoring worked, while its one trigger stayed quiet through the worst deploy in the test.

AI-assisted debugging

Neither tool has an assistant inside its interface that I could test, so this section isn't a head-to-head.

AppSignal: An MCP server, untested

I saw no AI features in AppSignal's app. Its documentation describes an MCP server, in beta, that lets an outside assistant read incidents, traces and metrics. I didn't try it.

GlitchTip: Copy for AI

Each GlitchTip event has a "copy for AI" link next to "raw JSON", visible in the error header shown earlier. It puts the event on your clipboard for pasting into whatever chat assistant your team uses, and I left it untried.

AI comparison

Verdict: Not compared. Both leave the analysis to an assistant outside the product, and I tested neither route.

Neither tool will look at a bad release for you, so diagnosis stays with whoever is on call. I also tested the 1.2.0 question in Better Stack: what changed since 1.1.0, and why? Its AI SRE checked releases, errors, traces and logs with no repository connected:

Notice that it found only the book lookup had slowed, so the database server wasn't the cause. Then it treated the payment failure separately, with 10 of 48 charges failing on 1.2.0 alone, and linked the new error. Pasting an event into a chat is quicker and free, while this answer needed roughly four minutes and $0.49, and it named both causes.

Ask AI SRE what your last deploy broke

Pricing

AppSignal charges by request volume and includes every feature on each plan. GlitchTip charges by event, where errors, transactions, logs and uptime checks share one pool.

These figures come from each vendor's pricing page on November 4, 2026. Vendors revise plans often, so confirm them when you sign up.

Free plans and trials

My GlitchTip test went past its free allowance halfway through. After the first full run, usage was already near half:

Most of that was performance data. By the end, the count reached 110%:

Events were still accepted with this warning banner. I didn't see when throttling would start.

Entry-level paid plans

Above Small, GlitchTip sells Medium, $50 a month for half a million events, and Large, $250 a month for 3 million.

What costs extra

Comparing the actual cost

At entry level, GlitchTip Small costs $15 a month, and AppSignal's first paid tier comes to about $23.25 a month on annual billing. The gap is small in dollars and large in what you get.

AppSignal's plan includes traces, slow queries, logs, host metrics and heartbeats. Those are what carried it through the performance and logs sections. GlitchTip's plan covers error capture and source lines, which held up well here, plus route averages and logs. To match AppSignal's view of a bad deploy, you'd be adding a tracing product to GlitchTip's bill.

The units differ too. AppSignal counts requests, so a busy API pays for traffic even when nothing fails. GlitchTip counts events, so a bad release that throws thousands of errors uses up the plan, though a spend cap keeps the bill in check. If you want on-call and status pages in the same bill, our comparison for AppSignal covers a platform that adds them.

Verdict: GlitchTip. It's the cheaper way to track errors, and the only one you can run yourself. AppSignal is the better buy once you want performance data in the same place.

Full feature comparison

Which should you choose?

Ask yourself whether your team needs to explain slow releases or just catch exceptions.

Choose AppSignal if a slow release worries you more than a crash

AppSignal showed the bad deploy as a per-release table, traced it to the slow query and kept each bug in one issue. Its logs, Time Detective, host metrics and heartbeats cover a small team's whole app, and the bill doesn't grow with overages.

The trade-offs showed up at the edges. It missed an unhandled rejection, couldn't parse ES module frames on the server, and the wizard assumes CommonJS. Its namespace-wide trigger also stayed quiet through the slowdown. If you're also weighing it against a larger platform, our Sentry vs AppSignal comparison covers that matchup.

Choose GlitchTip if you want Sentry-compatible error tracking on a small budget

GlitchTip caught every planted failure, showed server source lines without a repository, and offers "Resolve in next release". It costs $15 a month hosted, and it's open source if you'd rather run it yourself. Because it uses Sentry's SDKs, moving to or from Sentry later is a DSN change.

Its grouping is the cost. Every amount, ID or run number in a message makes a new issue, so expect to merge by hand. Performance stays empty on SDK 11 until you set the static lifecycle, and even then you get averages with no traces. For the same SDKs on the original platform, see our Sentry vs GlitchTip comparison.

FAQ

Does GlitchTip work with the Sentry SDK?

Yes. GlitchTip has no SDK of its own and accepts events from Sentry's SDKs with a GlitchTip DSN. With Sentry SDK 11, set traceLifecycle: 'static', or GlitchTip won't record any performance data.

Does AppSignal catch unhandled promise rejections in Node.js?

It didn't in my test. The rejection showed up only as a log line my app wrote, and its route reported a 0% error rate.

Can you self-host GlitchTip?

Yes. GlitchTip is open source, so you can run it on your own servers for free. AppSignal is a hosted service only.

Which has better performance monitoring?

AppSignal, by a wide margin in this test. It has traces, per-deploy comparisons and a slow-query ranking. GlitchTip shows average duration per route, with no trace view or release filter.

Final thoughts

The real decision is which failure you can afford to miss. GlitchTip sees every exception, including the quiet ones, and then buries a single new bug under a row for every value in its message. AppSignal keeps the bug in one place and explains the slow request around it, but it let an unhandled rejection pass as a success.

A bad deploy in production usually shows up as slowness before it shows up as an error. If your team only reads the error list, GlitchTip will report 1.2.0 as seven small bugs and a slightly slower checkout.

Choose GlitchTip if affordable, Sentry-compatible error tracking is enough. Choose AppSignal if you need to investigate slow deployments, database queries and infrastructure health alongside exceptions. Neither was perfect in this test, but the difference in what each could explain was clear.

Got an article suggestion? Let us know

Explore more

Better Stack vs AppSignal: A Complete Comparison for 2026

Better Stack vs AppSignal: an honest, detailed comparison of architecture, performance monitoring, error tracking, pricing, and AI features to help you pick the right tool in 2026.

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 AppSignal: Hands-On Error Tracking Comparison for 2026

I tested Sentry and AppSignal on the same buggy Node.js app across three releases, comparing error capture, debugging, release tracking, tracing, host monitoring, AI and pricing to show where each one pulls ahead.

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

tested Sentry and GlitchTip on one Node.js app over three releases, comparing setup, grouping, release tracking, performance, logs and pricing. GlitchTip is cheaper, and Sentry explains more.

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