Sentry and AppSignal both help you monitor application errors and performance, but they approach troubleshooting differently. Sentry connects error tracking with distributed tracing, session replay, logs, profiling, and AI-assisted debugging, while AppSignal combines application performance monitoring, error tracking, infrastructure metrics, logs, and uptime monitoring in one platform.
I tested both tools using the same Node.js bookstore application, introducing backend exceptions, browser errors, slow database queries, and recurring bugs across three releases. I wanted to see how well each platform detected problems, helped identify their causes, and showed what changed after a deployment.
Both platforms detected the major checkout performance regression, but their results revealed important differences. AppSignal made the slowdown immediately visible in its release comparison, showing that average checkout time had increased from 2 milliseconds to 4.59 seconds. However, the slow-response alert I configured never fired, even though checkout had become dramatically slower.
Sentry provided stronger debugging context, connecting browser errors to backend traces and retaining the database spans responsible for slow requests. It also caught an unhandled promise rejection that AppSignal missed in my setup. AppSignal performed better at error grouping and infrastructure monitoring, keeping issues stable across releases while providing host metrics, process monitoring, and useful performance dashboards.
Neither platform was perfect. Sentry created duplicate issues after code changes, while AppSignal couldn't display my server source code correctly and lost child spans on failing checkout requests.
This hands-on comparison covers setup, error capture, debugging, grouping, real user monitoring, release tracking, performance, logs, infrastructure monitoring, AI capabilities, and pricing, using screenshots and results from my October 2026 tests.
Before getting into the individual tests, here's how both platforms performed across the main areas I evaluated.
These results reflect my Node.js and Express application, along with the SDK versions and configuration I used. Other environments may produce different results.
| Area | Better in my test | Why |
|---|---|---|
| Setup | Sentry | Worked with my ES module application without additional instrumentation |
| Error capture | Sentry | AppSignal missed an unhandled promise rejection and reported some failed requests twice |
| Debugging | Sentry | Displayed backend source code and connected browser errors to server traces |
| Error grouping | AppSignal | Kept existing errors together after code changes |
| Real user monitoring | Sentry | Provided session replay and a ready-made Web Vitals dashboard |
| Release tracking | Sentry | Clearly marked returning errors as regressions |
| Performance monitoring | Tie | AppSignal surfaced slow releases and queries automatically; Sentry kept spans on failing requests |
| Logs and events | Mixed | Sentry connected logs to traces; AppSignal offered Time Detective and custom metric dashboards |
| Infrastructure monitoring | AppSignal | Collected host metrics and monitored processes with little configuration |
| Uptime and alerts | Mixed | AppSignal's heartbeat monitoring worked, but its slow-response trigger didn't fire |
| AI-assisted debugging | Not compared | Sentry's Seer was tested; AppSignal's MCP integration wasn't |
| Pricing | AppSignal | More predictable request-based pricing without automatic overage charges |
To compare both platforms under realistic conditions, I used monitoring-lab, a deliberately unreliable online bookstore.
The application includes an Express 5 API backed by SQLite, a Vite storefront, an external price service that occasionally fails, and a reporting job that runs every minute.
Both monitoring platforms were connected to the same application through separate adapters.
This meant I could introduce identical bugs and compare how each platform captured and explained them without changing the application's core behavior.
The application contained several predictable failure scenarios:
TypeError, while requesting a nonexistent book caused another exception.Three simulated customers, alice, bob, and carol, interacted with the application through direct API calls and headless Chromium sessions.
This generated enough traffic to examine error grouping, request context, performance trends, and release behavior.
I deployed three versions of the application.
| Release | What I tested |
|---|---|
| 1.0.0 | Initial setup, error capture, source maps, breadcrumbs, user context, tracing, and logs |
| 1.1.0 | A previously resolved coupon error returning after deployment |
| 1.2.0 | A faulty deployment introducing a slow database query and intermittent payment failures |
The final release was particularly important because it introduced two independent problems.
First, checkout became much slower because a database query started taking seconds instead of milliseconds.
Second, the payment operation began failing on every fifth attempt.
The payment failures produced exceptions, but the database slowdown didn't throw an error. That distinction made it possible to evaluate whether each platform could detect performance regressions independently of exception tracking.
I used the following packages:
| Platform | SDKs |
|---|---|
| Sentry | @sentry/node, @sentry/browser, and @sentry/profiling-node 11.8.0 |
| AppSignal | @appsignal/nodejs 3.9.4 and @appsignal/browser 1.0.0-beta.9 |
A few conditions are worth understanding before interpreting the results.
I corrected two mistakes in my initial AppSignal integration. My database spans originally used a separate OpenTelemetry instance, and handled errors were reported outside their associated requests. I fixed both issues and used the corrected integration for the comparison.
However, I left AppSignal's own behavior unchanged, including its failure to capture the unhandled promise rejection.
Each platform also received a separate traffic run, approximately five days apart. Event totals therefore shouldn't be compared directly.
For infrastructure monitoring, I ran AppSignal on an Ubuntu server because its host metrics weren't available on my Mac.
Sentry's AI assistant had access to my GitHub repository, while AppSignal's MCP integration wasn't tested.
Finally, the results reflect Node.js and Express. Other frameworks and SDKs may behave differently.
With those conditions established, here's how the platforms compared.
Both platforms accepted telemetry from the browser and server, but the initial configuration experience was different.
Sentry offered a more straightforward setup for my ES module application, while AppSignal's onboarding focused on a CommonJS configuration.
During project creation, Sentry detected my GitHub repository and suggested Express and Browser JavaScript as platforms.
The setup page then presented several monitoring capabilities that could be enabled together.
Errors, logs, metrics, tracing, and profiling were enabled in the generated configuration.
The snippet also included my project's DSN, so I didn't need to manually copy the connection details into each integration.
The browser and server used the same project and DSN.
Once the application started generating traffic, both types of errors appeared in the same issue list.
The main advantage was that the generated setup worked with my application without requiring changes to the instrumentation approach.
However, enabling every signal also means collecting more telemetry, so it's worth reviewing the defaults before using the configuration in production.
AppSignal's onboarding begins by asking which application platform you want to monitor.
Node.js is presented as a Full APM integration, while Browser JavaScript is described as supporting error monitoring.
Other languages, including Go, PHP, and Java, use OpenTelemetry-based integrations.
After selecting Node.js, the wizard explains the package installation and framework-specific configuration.
For Express, it shows where to register the error handler.
The handler belongs after the application's routes and before other error-handling middleware.
That part was straightforward.
The difficulty appeared when configuring the SDK itself.
The wizard generated a CommonJS configuration using an appsignal.cjs file.
It expected the application to load that file with Node.js's --require option.
My bookstore uses ES modules, and the generated configuration didn't instrument Express correctly in that environment.
I had to register an ES module instrumentation hook manually before requests appeared as traces.
This wasn't a problem with AppSignal's ability to monitor Express. It was a limitation of the setup path presented by the wizard for my application.
My first connection attempt also failed because I'd accidentally left a placeholder API key in .env.
AppSignal responded with a useful diagnostic screen, pointing me toward its log file and troubleshooting command.
Once the configuration was corrected, telemetry began arriving.
The dashboard displayed error rate, throughput, and response-time charts.
It also marked the first deployment using the revision value configured in the SDK.
That was a useful detail because AppSignal connected application versions to performance data without requiring a separate deployment API call.
| Capability | Sentry | AppSignal |
|---|---|---|
| Frontend and backend in one place | One project and DSN | One application with separate namespaces |
| Repository detection | Suggested platforms | Not observed |
| Express setup | Worked from generated snippet | Required manual ES module hook |
| ES module support in onboarding | Worked in my test | Wizard showed CommonJS |
| Release identification | SDK release value | revision setting |
| Deployment markers | Available | Automatically displayed on charts |
| Troubleshooting failed setup | Not needed | Diagnostic logs and commands |
Verdict: Sentry. Its generated configuration worked with my ES module application, while AppSignal required additional instrumentation work. AppSignal's wizard was clear, but its CommonJS focus made setup less convenient for my project.
Error tracking starts with a simple requirement: the monitoring platform must record application failures reliably.
Both platforms detected most of the problems I introduced, but Sentry performed better on two important edge cases.
After the first release, Sentry displayed 11 issues covering backend failures, browser exceptions, and the background reporting job.
The list included the unhandled promise rejection from the recommendation service.
Its error message, "Recommendation engine timed out", appeared as a separate issue with six events.
Sentry also included replay counts on browser-related issues, making it easy to identify which exceptions had accompanying session recordings.
The deliberately missing cover image didn't generate an issue, although it later appeared as a failed network request inside a replay.
AppSignal captured the main backend exceptions and browser crashes.
Its error list after the corrected integration contained 12 issues, including one left over from my earlier adapter configuration.
AppSignal organized errors using their class and the action where they occurred.
For example, a TypeError on GET /books/:id appeared separately from an API error on /orders.
However, two behaviors stood out.
First, AppSignal didn't capture the unhandled promise rejection as an error.
The /broken-promise endpoint ran seven times, but AppSignal reported a 0% error rate for that action.
The recommendation timeout appeared only because my application explicitly logged it.
The log contained "Recommendation engine timed out for user anonymous" as an attribute.
Without that application-generated log, the failure wouldn't have appeared in the data I inspected.
The second issue involved browser requests.
AppSignal's beta browser SDK automatically reported failed fetch requests as HTTPError.
My application also reported those failures as ApiError.
As a result, some failed requests appeared twice, once from the browser SDK and once from my application's own reporting.
This affected failures on routes such as /books/:id and /checkout.
The duplicate reporting came from the combination of automatic and manual error capture, so it's something you'd want to account for when configuring the browser SDK.
| Test | Sentry | AppSignal |
|---|---|---|
| Backend exceptions | Captured | Captured |
| Browser crashes | Captured | Captured |
| Handled errors | Captured | Captured |
| Background job failures | Captured | Captured |
| Unhandled promise rejection | Captured as an issue | Appeared only in application logs |
| Failed browser requests | One application-reported issue | Automatic HTTPError plus manual ApiError |
| Missing cover image | Visible in session replay | Not reported |
Verdict: Sentry. It captured every introduced exception, including the unhandled promise rejection. AppSignal missed that rejection in my setup and duplicated some browser failures because of overlapping automatic and manual reporting.
AppSignal missed the unhandled recommendation failure as an error and reported some browser failures twice.
I also sent the same test scenarios to Better Stack.
The recommendation timeout appeared among the backend errors with six events, alongside errors captured from the storefront.
However, errors the storefront caught and handled itself didn't become separate error-list entries. Those appeared only within their associated session events.
Capturing an error is only the beginning.
The next challenge is understanding what caused it and finding the relevant source code, request details, and related activity.
I compared stack traces, breadcrumbs, user context, and the ability to connect frontend and backend failures.
Sentry displayed the wishlist crash with its original source code after I uploaded source maps using sentry-cli.
The issue highlighted line 122 of pages.js, where the application attempted to add a book to an undefined wishlist.
This made the failure understandable without opening the source code in a separate editor.
Sentry also displayed source code for backend exceptions.
The payment error showed the relevant condition at server.js:173, where the application deliberately failed every fifth payment.
Each backend frame also offered a GitHub link, allowing me to open the corresponding source location.
However, the more important advantage appeared when investigating an error that crossed from the browser into the backend.
A failed checkout generated two different errors.
The browser reported that the checkout API request failed, while the backend reported the exception responsible for the failure.
Sentry connected those events through distributed tracing.
The browser issue displayed a related server error in its trace preview.
Opening the trace revealed the request's complete execution path.
The trace contained 12 spans covering the shopper's click, the browser's HTTP request, the Express handler, and the database operation.
The backend error also included the shopper's session replay because the browser passed the replay identifier with its request.
This connection made it possible to move from the error a shopper experienced to the backend operation responsible for it.
AppSignal also supported browser source maps.
After uploading the relevant files through its API, the wishlist crash displayed the original source location.
The relevant source lines appeared with the failing statement highlighted.
AppSignal also provided application and full-backtrace options, making it easier to focus on application code rather than library frames.
Its automatic browser breadcrumbs were particularly useful.
The breadcrumb timeline included network requests with status codes and durations.
It also recorded the click on the "Add to wishlist" button, including the element and its position.
My application's own breadcrumb appeared immediately before the exception.
This provided a clear sequence of events leading to the browser crash.
Unfortunately, the backend debugging experience wasn't as complete.
The backend error pages displayed stack frames, but the application frames weren't parsed correctly.
Each application frame contained a warning about failing to parse the line number.
The paths used file:// URLs, which are common in Node.js ES module stack traces.
AppSignal displayed the file path but couldn't show the corresponding source code.
This affected every server error I opened during the test.
The behavior may differ with CommonJS applications or other runtime configurations, so I wouldn't treat it as a universal AppSignal limitation.
However, it made debugging my Express application more difficult.
AppSignal retained other useful information.
For example, the coupon error included the request payload.
The payload contained the book ID, quantity, and invalid coupon code.
User details were stored as tags such as user_email.
Unlike the browser SDK, AppSignal's Node.js integration didn't provide a dedicated breadcrumb API in my setup. I stored the checkout steps as custom data instead.
Those appeared as JSON rather than a breadcrumb timeline.
AppSignal also didn't connect the browser's failed checkout to the corresponding backend exception.
The browser error had its own span, while the backend trace didn't show a browser parent.
| Capability | Sentry | AppSignal |
|---|---|---|
| Browser source maps | Working | Working |
| Backend source code | Displayed inline | Frames couldn't be parsed in my ES module application |
| GitHub source links | Available | Not observed |
| Request payload | Available | Available |
| User context | Dedicated fields | Custom tags |
| Browser breadcrumbs | Automatic | Automatic, with detailed timing |
| Backend breadcrumbs | Available | Custom JSON in my setup |
| Browser-to-backend tracing | Connected | Not observed |
| Replay attached to backend errors | Supported | Not available in my test |
Verdict: Sentry. Both platforms provided readable browser errors, and AppSignal's automatic breadcrumbs were particularly detailed. However, Sentry offered stronger backend debugging and connected frontend failures to their server-side causes.
AppSignal kept the browser failure and backend exception separate, while Sentry connected them through a shared trace.
I also investigated the same checkout failure in Better Stack.
The server exception included direct links to related logs, spans, releases, and session replays.
Opening the associated session displayed frontend and backend activity together.
The timeline contained 30 frontend spans and seven backend spans, making it possible to follow a browser interaction into its corresponding server operations.
The browser integration was still in beta during my test, and I couldn't resolve the storefront's source maps.
Error grouping determines whether repeated failures appear as one issue or several.
Grouping errors too broadly can hide unrelated bugs, while splitting the same underlying failure creates duplicate issues and unnecessary triage work.
This was an area where AppSignal performed particularly well.
AppSignal grouped errors using their class and the action where they occurred.
For HTTP requests, that generally meant the endpoint responsible for the failure.
For example, my storefront used one API helper that threw ApiError for different failed requests.
AppSignal still kept failures from /orders, /books/:id, and /checkout separate.
This grouping approach also remained stable across releases.
The coupon error remained in its original group after the checkout code changed.
The new payment error also appeared as one group, even though individual failures contained different payment amounts in their messages.
AppSignal didn't create duplicate groups when release 1.2.0 changed the checkout code.
That made the error list easier to interpret after deployment.
The main limitation was that errors occurring outside a named request or span could be grouped under a generic action.
My background reporting job, for example, used a generic "Error" action unless it ran inside a named span.
Sentry also kept most failures organized correctly.
Its stack-based grouping handled the original errors and the payment failures without splitting them by message values.
However, release 1.2.0 changed the checkout code and shifted the stack traces for existing errors.
Sentry interpreted those changes as new issues.
The coupon error and out-of-stock error each appeared in additional groups.
Neither was a new bug.
Their stack traces had changed enough for Sentry to create separate issues.
Sentry also made the opposite grouping mistake in the browser.
The frontend's checkout failure group absorbed the new payment failures because they originated from the same browser-side API helper.
This meant different backend failures appeared under one browser issue.
Sentry offers fingerprint rules to customize grouping, which can help correct these situations.
However, the default behavior wasn't as stable as AppSignal's during this test.
| Scenario | Sentry | AppSignal |
|---|---|---|
| Errors from one shared API helper | Separate groups | Separate groups by route |
| Payment error with changing amounts | One issue | One issue |
| Coupon error after code changes | Created a duplicate | Kept original group |
| Out-of-stock error after code changes | Created a duplicate | Kept original group |
| Errors outside named requests | Grouped by stack | Generic action without a named span |
| Grouping customization | Fingerprint rules | Not tested |
Verdict: AppSignal. Its error-class and action-based grouping kept the original bugs stable across all three releases. Sentry handled changing error messages well but created duplicate issues when the checkout code changed.
Real user monitoring helps you understand application performance from the visitor's perspective.
Session replay adds another layer by showing what users did before encountering an error.
Sentry provides both capabilities, while AppSignal's browser monitoring focuses on errors, breadcrumbs, and performance metrics.
Sentry recorded the storefront sessions with text masked by default.
Opening a replay displayed an AI-generated summary of the session.
The summary described the user's actions and highlighted the wishlist failure.
The events matched the traffic I generated.
The replay also included a Network tab containing the browser's requests.
That tab revealed the deliberately broken cover image returning HTTP 404.
Neither platform had reported the missing image as an exception, so the replay provided context that ordinary error tracking missed.
Sentry also collected browser performance metrics and displayed them in a ready-made Web Vitals dashboard.
The storefront received an overall score of 90.
Its 75th-percentile Largest Contentful Paint was approximately 92 milliseconds, while Time to First Byte reached 2.51 seconds.
However, the page breakdown had a limitation.
My storefront used hash-based routes, and Sentry grouped every page under /.
As a result, I couldn't identify the deliberately slow book page from the default route breakdown without configuring custom transaction names.
AppSignal's beta browser SDK also collected Web Vitals.
However, it didn't provide the same ready-made dashboard.
Instead, the measurements were exposed as custom metrics, including browser_webvital_lcp and browser_webvital_inp.
These could be added to dashboard charts.
The chart builder offered counts, averages, and percentile calculations.
Metrics also included tags such as page_url and app_version, allowing performance to be analyzed by page and release.
This provided flexibility, but required more manual work.
I also didn't find a session replay feature in AppSignal's interface.
Its automatic browser breadcrumbs, covered earlier, were the closest alternative for understanding user interactions before an error.
| Capability | Sentry | AppSignal |
|---|---|---|
| Session replay | Available and tested | Not observed |
| AI replay summaries | Available | Not offered |
| Network request history in replay | Available | No replay |
| Web Vitals | Ready-made dashboard | Custom metrics |
| Overall performance score | Available | Requires custom analysis |
| Per-page metrics | Limited by hash routes | page_url tags, not fully tested for hash routes |
| Browser breadcrumbs | Automatic | Automatic, with detailed context |
Verdict: Sentry. Its session replay and ready-made Web Vitals dashboard provided a more complete browser monitoring experience. AppSignal collected useful performance metrics, but required custom dashboards and didn't offer replay in my test.
Release tracking helps answer two questions: what changed after a deployment, and did an error you previously fixed return?
I tested this by marking the coupon error as resolved during release 1.0.0 and then deploying release 1.1.0 without fixing it.
Both platforms reopened the error, but Sentry explained what had happened more clearly.
Sentry allows you to resolve an issue immediately or associate its resolution with a later release.
I selected "The next release".
When the same coupon error appeared in release 1.1.0, Sentry reopened it.
The issue list immediately identified the error as Regressed.
The regression label appeared directly beneath the issue's activity graph.
That made it possible to identify the returning bug without opening the error.
Sentry also recorded the regression in the issue's activity history.
The release page included a dedicated Regressed tab.
That tab contained exactly one issue, the coupon error.
The activity history had a minor wording issue in one instance, comparing release 1.1.0 with itself rather than the previous release.
However, the regression was still clearly identified.
AppSignal's error status menu offered three states: Open, Work in progress, and Closed.
The interface explained that a new notification would reopen a closed incident.
Unlike Sentry, it didn't offer an option to resolve an error specifically for the next release.
After deploying release 1.1.0, the coupon error reopened automatically.
However, the error page simply displayed an Open status.
There was no label indicating that the issue had previously been resolved.
The Logbook didn't record the automatic reopening either.
It showed my manual change from Open to Closed, but nothing documenting the subsequent reopening.
This made it difficult to distinguish a returning bug from an issue that had never been resolved.
Although AppSignal didn't mark regressions explicitly, it offered useful ways to inspect errors by deployment.
Its error list included a "Most recent revisions" filter.
This restricted the list to errors occurring in the selected release.
Each row also displayed how many events belonged to that selection compared with its all-time count.
For the coupon error, five of its 30 events appeared in the new release.
AppSignal's Deploys page also showed error rates for individual revisions.
Release 1.1.0 showed approximately 876 errors per hour during its initial minutes, compared with 273 per hour for release 1.0.0.
These views were useful for evaluating release health, even though they didn't clearly identify returning bugs.
| Capability | Sentry | AppSignal |
|---|---|---|
| Automatic release identification | Yes | Yes, through revision |
| Resolve for a future release | Yes | No |
| Reopen returning errors | Yes | Yes |
| Regression label | Yes | No |
| Regression activity history | Available | Not recorded in my test |
| Errors by release | Dedicated release views | Revision filters |
| Deployment performance markers | Available | Available |
| Error rates by deployment | Available | Available |
Verdict: Sentry. Both platforms reopened the coupon error correctly, but Sentry clearly identified it as a regression. AppSignal provided useful deployment filters without explaining that the error had previously been resolved.
AppSignal reopened the coupon error without recording the change in its Logbook, while Sentry displayed a regression label but created duplicate issues for older bugs after the checkout code changed.
I also deployed the same releases to Better Stack.
The returning coupon error appeared with a red "Reoccurred" status in the error list.
Its activity history recorded the sequence of events.
The original error, resolution, and subsequent reoccurrence remained associated with the same issue.
Across all three releases, the coupon error stayed in one group.
Sentry still offered a dedicated Regressed tab on its release pages, which Better Stack didn't provide in my test.
Performance monitoring was one of the most interesting parts of this comparison because both platforms successfully identified the checkout slowdown.
However, they presented the information differently.
AppSignal made the regression easier to notice through its built-in release comparisons and query rankings. Sentry provided more complete evidence on individual failing requests.
AppSignal collected request durations and performance information through its Node.js integration.
After correcting my OpenTelemetry configuration, database spans also appeared in request traces.
During the initial release, checkout was fast.
The database SELECT operation took approximately 458 microseconds, while the INSERT took 799 microseconds.
The entire request completed in roughly four milliseconds.
After deploying release 1.2.0, AppSignal's action summary showed a dramatic change.
The "Performance in the last deploys" section compared average request duration across releases.
Checkout averaged approximately two milliseconds in releases 1.0.0 and 1.1.0.
In release 1.2.0, that average increased to 4.59 seconds.
I didn't need to create a custom chart or write a query to discover the regression.
AppSignal displayed the comparison automatically.
Opening a slow checkout trace revealed how the request spent its time.
The trace included a SELECT operation lasting approximately 3.06 seconds, along with other expensive operations in the checkout flow.
AppSignal also provided a dedicated Slow queries page.
The SELECT book for checkout query accounted for 67.6% of database impact, with an average duration of 1.03 seconds.
That made it easy to identify which database operation had become expensive.
The Slow API requests page provided similar information for outgoing HTTP calls.
It ranked the unreliable price service with an average duration of approximately 3.21 seconds.
Together, these pages gave AppSignal a strong advantage for quickly finding slow operations without extensive custom queries.
The weakness appeared when I investigated a checkout request that failed with the payment error.
The request took approximately 3.34 seconds, but the trace contained only its root span.
The database query and payment operation were missing.
Instead of explaining where the time went, the breakdown classified the entire request duration as "Other".
This was a significant limitation because the failing checkout was precisely the request I wanted to investigate.
AppSignal's aggregate performance reports identified the slowdown, but the error's own trace didn't contain the operations needed to explain it.
Sentry also detected the slowdown.
Its trace for a failing checkout in release 1.2.0 showed the database query and payment operation together.
The request took approximately 2.26 seconds.
Of that time, 1.79 seconds were spent in the book lookup query.
The payment operation then failed after approximately 459 milliseconds.
Unlike AppSignal's failing trace, Sentry retained the child spans needed to explain the request.
Sentry also allowed me to compare performance across releases using Trace Explorer.
Checkout's 95th-percentile duration increased from 5.29 milliseconds and 3.63 milliseconds in the first two releases to 5.93 seconds in release 1.2.0.
That connected the slowdown to the faulty deployment.
However, unlike AppSignal's built-in release comparison, I had to configure the Trace Explorer view and group the results by release.
Sentry's profiler wasn't useful for this particular regression because the database operation spent its time waiting rather than consuming CPU.
| Capability | Sentry | AppSignal |
|---|---|---|
| Request tracing | Browser to database | Server requests and operations |
| Database spans | Available | Available after corrected instrumentation |
| Slow query identification | Individual trace | Slow queries page |
| Release performance comparison | Trace Explorer configuration | Automatic release comparison |
| Request latency percentiles | Available | Available |
| Child spans on failing checkout | Preserved | Missing in my test |
| Outgoing API performance | Trace information | Dedicated Slow API requests page |
| CPU profiling | Available | Not tested |
Verdict: Tie. AppSignal made the performance regression easier to discover through automatic release comparisons and query rankings. Sentry provided more reliable request-level debugging by preserving the database and payment spans on the failing checkout.
AppSignal identified the slow database query but lost the child spans from the checkout request that failed. Sentry retained those spans, although the application's own log warnings appeared in a separate tab.
I investigated the same faulty release in Better Stack.
The failing request took 2.19 seconds.
The book query accounted for 1.53 seconds, while the payment operation took another 660 milliseconds.
The corresponding logs were also available from the same request.
The slow-query warning appeared immediately before the checkout failure, connecting the measured delay to the application's own explanation.
The Service column remained empty because my SDK configuration didn't set a service name.
Logs provide the application-level details that traces and error reports don't always capture.
Both Sentry and AppSignal stored structured logs during my test.
However, Sentry connected logs more directly to individual requests, while AppSignal offered useful tools for investigating activity across the wider application.
Sentry's Logs explorer displayed the application's structured log entries.
It also provided a Logs tab within each trace.
For a failed checkout, browser and server log entries appeared in chronological order.
Each error-related entry was also associated with its corresponding issue.
This made it easier to understand what happened during one request without manually searching for matching timestamps or identifiers.
Sentry also displayed application metrics alongside issues.
For example, browser performance metrics could appear directly on error pages.
AppSignal's logging integration worked without additional configuration.
Its Logging interface included severity, hostname, and live-tailing capabilities.
The reporting job generated log entries every minute, while checkout failures and upstream price errors appeared alongside them.
However, AppSignal didn't associate my logs with individual traces.
Its error pages displayed "No related log lines found", even though the application had logged the failures.
This meant I couldn't move directly from an exception to the corresponding log entries.
AppSignal compensated with another feature that worked particularly well: Time Detective.
Time Detective provides a synchronized view of errors, performance, alerts, host activity, and logs at a particular point in time.
During the faulty release, I inspected a minute when checkout performance had deteriorated.
At that point, POST /checkout averaged 4.76 seconds, with a 90th-percentile duration of 7.23 seconds.
Other operations, including book lookups, remained much faster.
This made Time Detective useful for understanding what else was happening when an application problem occurred.
Instead of investigating one request, it presented a broader snapshot of application behavior.
AppSignal collected the application's custom order and revenue metrics.
I used its dashboard builder to visualize those values.
The resulting dashboard included an orders chart grouped by coupon and a revenue chart.
Deployment markers appeared on the charts, making it possible to relate business metrics to application releases.
However, building each chart required several configuration steps.
The metric picker also depended on tag combinations that AppSignal had already observed.
Once configured, the dashboards were useful for tracking application behavior beyond technical performance.
| Capability | Sentry | AppSignal |
|---|---|---|
| Structured logs | Available | Available |
| Live log viewing | Available | Available |
| Logs linked to requests | Yes | Not working in my setup |
| Logs linked to errors | Yes | Not working in my setup |
| Application-wide time analysis | Through individual views | Time Detective |
| Custom metrics | Available | Available |
| Business metrics dashboards | Supported | Supported |
| Deployment markers on charts | Available | Available |
Verdict: Mixed. Sentry was better for investigating logs associated with a specific failing request. AppSignal's Time Detective and custom dashboards were useful for understanding broader application behavior during a particular period.
AppSignal's broader operational monitoring capabilities became more apparent when I moved the application from my Mac to an Ubuntu server.
Unlike the earlier sections, this part of the test focused on infrastructure and process health rather than individual application errors.
AppSignal collected host metrics automatically and successfully detected when I stopped the monitored process.
However, its slow-response alert didn't behave as I expected.
After starting the application on Ubuntu, the server appeared in AppSignal's Host metrics view.
The page displayed the operating system, kernel, load average, memory usage, and disk utilization.
It showed approximately 665 MB of memory used out of 1.86 GB, with disk usage at 16%.
I didn't need a separate infrastructure agent configuration for these metrics.
The host detail page provided additional CPU and memory charts.
CPU utilization approached 90% while I installed dependencies, built the application, and generated test traffic.
Deployment markers also appeared on the infrastructure charts, making it possible to relate resource usage to software releases.
AppSignal also provided a Host usage view.
This compared request performance and error rates across the machines running the application.
My Mac averaged approximately 485 milliseconds per request with a 7.06% error rate.
The Ubuntu server averaged 1.28 seconds with a 21% error rate.
Those differences reflected the workloads rather than the machines themselves.
The server only ran the faulty release, while my Mac had also processed the earlier versions.
Even so, the view was useful for comparing application behavior across hosts.
AppSignal also supports process monitoring through heartbeats.
I tested this using its appsignal-run wrapper.
First, I created a process monitor called monitoring-lab in the interface.
I configured a two-minute heartbeat limit.
The important setup detail was that the monitor needed to exist before starting the process.
Without a matching monitor, the wrapper didn't report a configuration error, but the heartbeats weren't recorded.
Once the monitor existed, I started the application through the wrapper:
AppSignal began receiving successful heartbeats approximately every 30 seconds.
I then stopped the application.
After the process stopped, AppSignal marked the heartbeat as Missed.
The change appeared approximately two to three minutes after the application went down.
This confirmed that AppSignal's process monitoring could detect when the monitored application stopped running.
The most surprising operational result came from AppSignal's alerting.
I configured a slow-response trigger for web requests taking longer than one second.
The configuration allowed me to select a namespace, but not a specific endpoint.
When release 1.2.0 made checkout dramatically slower, I expected the trigger to identify the problem.
However, the anomalies list remained empty.
The reason became clearer when I examined the surrounding traffic.
Fast requests outnumbered the slow checkout requests, so the overall namespace average didn't cross the configured threshold.
A lower threshold might have detected the problem, but it would also have triggered during normal traffic in the earlier releases.
This exposed an important distinction between monitoring performance and detecting regressions.
AppSignal showed the slowdown clearly in its performance reports, but the namespace-wide trigger I configured didn't alert on the affected endpoint.
That doesn't establish that AppSignal can't alert on slow endpoints in other configurations. It does show that this particular trigger was insufficient for the failure I introduced.
Sentry also offers uptime and cron monitoring, but I didn't test those capabilities.
I didn't evaluate its alert rules against the same performance regression either.
Consequently, this section shouldn't be interpreted as a direct comparison of alert reliability.
AppSignal's infrastructure and process monitoring were tested, while the corresponding Sentry capabilities weren't evaluated.
| Capability | Sentry | AppSignal |
|---|---|---|
| Host CPU and memory metrics | Not observed | Automatic on Ubuntu |
| Disk and system metrics | Not observed | Available |
| Performance by host | Not evaluated | Available |
| Process heartbeat monitoring | Cron monitors not tested | Tested successfully |
| Uptime monitoring | Available, not tested | Available, not tested |
| Public status pages | Not evaluated | Available, not tested |
| Slow-response alert | Not tested | Configured trigger didn't fire |
| Heartbeat failure detection | Not tested | Detected stopped process |
Verdict: AppSignal for infrastructure and process monitoring. Its host metrics and heartbeat monitoring worked with minimal configuration. However, the slow-response trigger failed to detect the checkout regression in my test, so its alerting behavior deserves careful evaluation before relying on it.
AI-assisted debugging can help investigate errors, identify root causes, and suggest code changes.
Sentry offers a built-in assistant called Seer.
AppSignal takes a different approach through an MCP integration designed for external AI tools.
I tested Seer with access to my GitHub repository, but didn't evaluate AppSignal's MCP server.
Seer analyzed the coupon error in approximately 15 seconds.
It correctly identified that the checkout handler accessed the discount property without validating the coupon lookup.
It also recognized that the invalid coupon wasn't one of the application's accepted codes.
The response referenced relevant source lines and proposed a reasonable fix.
When I tested the payment error from release 1.2.0, Seer also identified the counter that caused every fifth payment to fail.
For these individual exceptions, the analysis matched the application code.
I then asked Seer Agent to explain why checkout had become slower after release 1.2.0.
The assistant correctly identified the increase in latency.
However, it attributed the slowdown to payment timeouts.
That explanation contradicted the trace data.
The database query was responsible for most of the delay and occurred before the payment operation.
A follow-up question didn't correct the explanation.
Seer identified the relevant performance numbers but drew the wrong conclusion about the cause.
This is worth remembering when using AI-generated incident analysis.
Even when an assistant has repository access, its conclusions should be checked against the telemetry.
AppSignal offers a beta MCP server that can connect its monitoring data to external AI tools.
According to the documentation available during my test, the integration supports operations such as listing incidents, retrieving stack traces, inspecting metrics, and working with dashboards.
This provides an alternative to a built-in assistant, particularly if you already use an AI development environment.
However, I didn't connect or test the MCP server.
I also didn't find an integrated AI investigation interface inside AppSignal during testing.
| Capability | Sentry | AppSignal |
|---|---|---|
| Built-in AI assistant | Seer | Not observed |
| Repository-aware analysis | Tested | Not applicable |
| Individual error root cause | Correct in my tests | Not tested |
| Performance regression explanation | Incorrect cause | Not tested |
| AI-generated fix suggestions | Available | Through external tools, not tested |
| MCP integration | Not tested | Beta, not tested |
Verdict: Not compared. Sentry's Seer correctly analyzed the code errors but misidentified the performance regression. AppSignal's MCP-based workflow wasn't tested, so there isn't enough evidence to compare AI investigation accuracy directly.
Seer correctly explained individual exceptions but attributed the checkout slowdown to the wrong operation.
I also asked Better Stack's AI SRE to investigate the same faulty release without giving it access to my repository.
AI SRE identified that the book query had slowed to approximately 2.6 seconds at the median, while other database statements remained close to their previous durations.
It then investigated the payment failures separately.
The analysis found that the new payment operation failed on 10 of 48 calls, all associated with release 1.2.0.
The investigation took approximately four minutes and cost $0.49.
It correctly separated the database slowdown from the payment failures, although it didn't identify the deliberate fifth-payment failure mechanism without repository access.
Sentry and AppSignal approach pricing differently.
Sentry provides separate quotas for errors, spans, session replays, and logs, with additional usage charged according to the relevant product.
AppSignal uses request-based pricing and includes its main monitoring capabilities within each plan.
Its pricing also avoids automatic overage charges, although sustained usage above the selected allowance can require moving to a higher tier.
The following figures reflect the pricing information collected on October 27, 2026. Verify current prices before purchasing.
Both platforms offer free plans.
| Feature | Sentry Developer | AppSignal Free |
|---|---|---|
| Monthly price | Free | Free |
| Users | 1 | Unlimited |
| Included usage | 5,000 errors, 5 million spans, 50 replays | 30,000 requests |
| Logs | 5 GB | 1 GB |
| Retention | 30-day lookback | 5 days |
| Paid-plan trial | 14-day Business trial | 30-day trial without a card |
| Session replay | Included allowance | Not observed |
Sentry's free plan provides broader monitoring capabilities, including tracing and session replay.
AppSignal's free plan is attractive for teams that need multiple users without paying immediately.
However, its five-day retention window is shorter.
The starting paid prices are relatively close.
| Feature | Sentry Team | AppSignal entry plan |
|---|---|---|
| Monthly price | $29 | Starts around $25 |
| Annual billing | $26/month equivalent | $279/year, approximately $23.25/month |
| Users | Unlimited | Unlimited |
| Included usage | 50,000 errors, 5 million spans, 50 replays | 250,000 requests/month |
| Logs | 5 GB | 1 GB/month |
| Retention | Up to 90-day lookback | Not confirmed in the pricing snapshot |
| Uptime monitoring | Included allowance | Included |
| Process monitoring | Cron monitoring | Included |
| Host metrics | Not evaluated | Included |
The AppSignal monthly starting price should be confirmed against its current billing calculator. The annual figure above comes from the pricing snapshot used for this comparison.
Sentry Business cost $89 per month, or $80 per month when billed annually.
The difference becomes more noticeable when monitoring usage increases.
| Additional usage | Sentry | AppSignal |
|---|---|---|
| Usage above included volume | Pay-as-you-go budget | Higher tier after usage review |
| Additional logs | $0.50/GB beyond included allowance | Long-term logging add-on |
| Long-term log storage | Usage-based | $89/month add-on in pricing snapshot |
| Additional uptime monitors | Per-monitor charges | Included in plan structure |
| Profiling | Usage-based | Not evaluated |
| AI-assisted debugging | Seer sold separately | External MCP integration |
| Automatic overage charges | Possible | Not charged |
AppSignal's request-based pricing makes the bill easier to predict, particularly when you want several monitoring capabilities under one subscription.
However, request volume can remain high even when errors are rare.
Sentry's pricing is more directly associated with the telemetry you collect, but multiple quotas and additional usage can make costs harder to estimate.
For small teams, the entry-level prices are similar.
Sentry Team cost $26 per month on annual billing, while AppSignal's annual entry plan worked out to approximately $23.25 per month.
The difference is what each subscription provides.
Sentry offers a more complete application debugging experience, including session replay, browser-to-backend tracing, profiling, and detailed error investigations.
AppSignal provides host metrics, process monitoring, uptime checks, logs, and application performance monitoring under a more predictable request-based model.
AppSignal also avoids automatic overage charges. Sustained higher usage can move you to a larger plan after a usage review rather than generating unexpected per-event charges.
If you also need incident management and on-call capabilities, our Better Stack vs AppSignal comparison covers another approach to combining monitoring with operational workflows.
| Consideration | Sentry | AppSignal |
|---|---|---|
| Free plan | Yes | Yes |
| Free-plan users | One | Unlimited |
| Entry paid price | $29/month | Around $25/month |
| Pricing model | Telemetry quotas | Request volume |
| Automatic overage charges | Possible | No |
| Session replay | Included in quotas | Not observed |
| Infrastructure metrics | Not evaluated | Included |
| Process monitoring | Cron capabilities | Included |
| Best fit | Teams prioritizing application debugging | Teams wanting broader operational monitoring with predictable billing |
Verdict: AppSignal on pricing predictability. Its plans bundle more operational monitoring capabilities without automatic overage charges. Sentry remains attractive when session replay, detailed traces, and profiling are the capabilities you value most.
The following table brings together the results from my testing.
| Feature | Sentry | AppSignal |
|---|---|---|
| Frontend and backend in one place | One project | One app, separate namespaces |
| ES module onboarding | Worked directly | Required manual instrumentation |
| Backend error capture | Captured all introduced failures | Missed unhandled rejection |
| Browser error capture | Worked | Worked, with duplicate failed-fetch reports |
| Browser source maps | Supported | Supported |
| Backend source code | Displayed inline | Frames unparsed in my test |
| Browser breadcrumbs | Automatic | Automatic, detailed |
| Backend breadcrumbs | Supported | Custom data in my setup |
| Frontend-to-backend tracing | Connected | Not observed |
| Error grouping after code changes | Two duplicate issues | No duplicates |
| Session replay | Available | Not observed |
| AI replay summaries | Available | Not offered |
| Web Vitals | Ready-made dashboard | Custom metrics |
| Release identification | Automatic | Automatic from revision |
| Regression label | Regressed | Plain Open status |
| Issue history for regression | Available | Not recorded |
| Request tracing | Browser to database | Server-side tracing |
| Database spans | Available | Available |
| Spans on failing checkout | Preserved | Root span only |
| Release performance comparison | Configurable Trace Explorer | Automatic comparison |
| Slow query ranking | Not tested | Available |
| Outgoing API ranking | Not tested | Available |
| Structured logs | Available | Available |
| Request-linked logs | Working | Not working in my setup |
| Time Detective | Not offered | Available |
| Custom metrics | Supported | Supported |
| Host metrics | Not observed | Automatic on Ubuntu |
| Process monitoring | Cron monitors, not tested | Heartbeat tested |
| Uptime monitoring | Available, not tested | Available, not tested |
| Slow-response trigger | Not tested | Didn't fire in my configuration |
| Built-in AI assistant | Seer | Not observed |
| MCP integration | Not tested | Beta, not tested |
| Permanent free plan | Yes | Yes |
| Free-plan users | One | Unlimited |
| Automatic overage charges | Possible | No |
Sentry and AppSignal overlap across error tracking, performance monitoring, and logging, but they have different strengths.
The best choice depends on whether your team spends more time investigating individual application failures or monitoring overall application and infrastructure health.
Sentry is the stronger option when you need to understand failures across the frontend and backend.
In my test, it captured every introduced exception, displayed readable source code, and connected browser errors to backend traces.
It also retained the database and payment spans on failing checkout requests, making it possible to identify the operations responsible for the slowdown.
Session replay and release tracking were additional strengths. Sentry showed what shoppers did before errors and clearly marked returning bugs as regressions.
However, there are trade-offs.
Its stack-based grouping created duplicate issues after code changes, Seer misidentified the cause of the checkout slowdown, and usage-based pricing can increase as telemetry volume grows.
Our Sentry vs Honeybadger comparison explores how it performs against another platform that combines error monitoring with logs and uptime checks.
AppSignal makes more sense when you're responsible for both application performance and the servers running it.
Its release comparisons, Slow queries page, and Time Detective made performance changes easy to investigate.
It also provided stable error grouping across deployments.
Infrastructure monitoring was another clear advantage. AppSignal automatically collected host metrics on Ubuntu and successfully detected when I stopped the monitored process.
Its request-based pricing also makes costs more predictable.
However, its debugging limitations deserve attention.
AppSignal missed an unhandled promise rejection in my setup, couldn't parse my backend source frames, and lost child spans on failing checkout requests.
It also reopened the returning coupon error without identifying it as a regression.
Most importantly, the slow-response trigger I configured didn't fire when checkout performance deteriorated, so you should carefully test its alert configuration against the specific endpoints that matter to your application.
Sentry performed better at error capture and debugging in my tests. It caught an unhandled promise rejection that AppSignal missed, displayed backend source code correctly, and connected browser errors to server traces.
However, AppSignal handled error grouping more consistently across code changes, keeping existing bugs in their original groups.
Yes. AppSignal supports application performance tracing and collects server-side request information, including database and external HTTP operations.
In my test, it identified slow database queries and displayed request traces. However, the failing checkout trace lost its child spans, and I didn't observe the same frontend-to-backend connection available in Sentry.
I didn't find session replay in AppSignal during my testing.
Its beta browser SDK provided error tracking, automatic breadcrumbs, and Web Vitals through custom metrics, but it didn't offer the session recordings available in Sentry.
Yes. AppSignal automatically collected host metrics on my Ubuntu server, including CPU, memory, and disk usage.
Its heartbeat monitoring also detected when I stopped the monitored application.
However, my slow-response alert didn't fire during the checkout regression because the configured trigger evaluated the broader namespace rather than the specific slow endpoint.
Both offer free plans, and their entry-level paid prices were relatively similar in my October 2026 pricing snapshot.
Sentry uses telemetry-based quotas for errors, spans, replays, and logs.
AppSignal uses request-based pricing without automatic overage charges, making its costs more predictable when your traffic fits the selected tier.
The better value depends on whether you need Sentry's deeper debugging capabilities or AppSignal's broader infrastructure and process monitoring.
Sentry and AppSignal both detected the major performance regression, but they differed in how effectively they helped me investigate and manage it.
Sentry provided stronger application debugging. It captured more errors, linked frontend failures to backend traces, preserved spans on failing requests, and clearly identified regressions. However, it created duplicate groups after code changes, and its AI assistant misdiagnosed the checkout slowdown.
AppSignal offered a broader operational view. Its release comparisons, query rankings, stable error grouping, and infrastructure monitoring were particularly useful. The main limitations were incomplete debugging context on failed requests and a slow-response trigger that didn't fire during my test.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
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.
New Relic vs AppSignal for 2026: a broad, seat-priced observability platform versus a focused, request-priced developer APM. Compare architecture, APM depth, logs, infrastructure, AI, pricing, and where each fits.
Sumo Logic is an enterprise observability-and-SIEM platform; AppSignal is a bootstrapped, developer-first APM with the deepest Ruby and Elixir instrumentation and request-based pricing. Compare application depth, security, AI, and 2026 pricing.
We use cookies to authenticate users, improve the product user experience, and for personalized ads. Learn more.