For a business application’s JavaScript error monitoring, the useful privacy question is what leaves the process before the dashboard receives it. Sentry, BugSnag, Rollbar, Airbrake and Honeybadger all provide client-side controls, but naming a sensitive field and removing sensitive text from every location are different jobs.
We installed the five Node.js SDKs and captured one deliberately constructed report from each on a local HTTP receiver. Explicit controls removed the value under access_token in all five reports. Our separate markers in the error message and an ordinary note remained. This is a narrow, reproducible client-payload finding; it is not a comparison of vendor security, hosted ingestion or regulatory compliance.
Five error monitoring platforms, one outbound-data question
| Platform and tested SDK | Explicit control used | Result in the local capture |
|---|---|---|
| Sentry, @sentry/node 11.8.0 | beforeSend changes one named context field | Key marker absent; note and message markers present |
| BugSnag, @bugsnag/js 9.1.0 | redactedKeys includes access_token | Key marker absent; note and message markers present |
| Rollbar, rollbar 4.0.0 | scrubFields includes access_token | Key marker absent; note and message markers present |
| Airbrake, @airbrake/node 2.1.9 | keysBlocklist includes access_token | Key marker absent; note and message markers present |
| Honeybadger, @honeybadger-io/js 6.17.0 | filters includes access_token | Key marker absent; note and message markers present |
Our actual payload experiment
Each report contained three different harmless canaries: KEY_CANARY_742 under a field named access_token, NOTE_CANARY_742 under note, and MESSAGE_CANARY_742 in the exception message. We placed metadata in the native context or parameter structure of each SDK, rather than assuming identical event schemas.
All five captured reports removed the key-field marker and retained both free-text markers. The intended key policy worked. The negative controls show why that policy cannot establish that arbitrary text is clean. A token copied into an error string, SQL fragment, URL, breadcrumb or attachment needs an appropriate separate control; only the message and note locations were exercised here.
The Sentry case deliberately used a one-field custom hook, while the other four used built-in key filters. These are explicit integration recipes, not equivalent defaults and not a ranking of built-in scrubbing completeness. We retained existing password coverage in the configured lists, but did not exhaustively test default fields, nested structures, regular-expression matching or key case sensitivity.
// Synthetic fixture, not a real credential:
const metadata = {
access_token: "KEY_CANARY_742",
note: "NOTE_CANARY_742"
};
const error = new Error("MESSAGE_CANARY_742");
// Inspect the captured outbound body, not only the hook input:
// KEY_CANARY_742 absent
// NOTE_CANARY_742 present
// MESSAGE_CANARY_742 presentThe buying implication is to shortlist a platform whose SDK control points match your data policy, then inspect the resulting serialized payload. A clean-looking dashboard cannot by itself establish that the original sensitive value never crossed the network.
Sentry
Sentry’s JavaScript filtering documentation exposes beforeSend for changing or dropping error events. Our hook changed only the access_token field in the scenario context. The receiver retained the note and exception markers, exactly as that narrowly scoped hook allowed.
This is useful when an engineering team wants to express an explicit event contract in code. It also makes the team responsible for the paths it chooses. An error-event hook should not be treated as proof that every other telemetry product is covered. We disabled default integrations in this experiment to isolate manual error capture; a production framework integration needs its own inspection.
The hosted plans package multiple telemetry types and allowances. No paid account or hosted scrubber was tested, and no total-cost or server-side privacy claim follows from these SDK results.
BugSnag
BugSnag documents redactedKeys and onError in its JavaScript configuration reference. The reference warns that supplying a custom redacted-key list replaces its default list. We therefore explicitly retained password coverage and added access_token.
The captured metadata value was redacted while the note and exception markers remained. For a team moving beyond standard metadata filtering, onError is a separate place to review the event. The practical tradeoff is maintaining configuration as the application adds metadata sections; setting one custom key must not accidentally erase other intended protections.
Check the current error-monitoring package and event capacity for the actual environment. Our local report used dummy credentials and does not verify event grouping, affected-user analysis, quotas or hosted retention.
Rollbar
Rollbar’s configuration reference distinguishes field scrubbing, path-based controls and a payload transformation function. We exercised an explicit scrubFields list with the marker in custom metadata, rather than testing the entire set of controls.
The key marker disappeared; the custom note and error text survived. That is a reason to map your policy onto payload locations before deciding that a key list is enough. A transform may be the appropriate place for a deliberately scoped rule, but our experiment does not establish its coverage for every possible payload.
Rollbar is a reasonable candidate when its structured payload and customization model fit the team’s error pipeline. Compare event allowances, retention and commercial terms separately from this client-side check. More filtering can also remove useful diagnostic context, so preserve a harmless operation identifier.
Airbrake
Airbrake’s JavaScript guide links to its notifier’s advanced configuration. The official notifier reference documents key blocking and custom filters. Our Node notifier used a blocklist containing password and access-token patterns, with the canaries under notice parameters.
The receiver saw neither the sensitive-key value nor a requirement for a real Airbrake account; it did see both free-text markers. Remote configuration and performance collection were disabled for the local test. That isolation is useful evidence about this error-report path, but limits any inference about a full default deployment.
Teams should evaluate whether the notice schema and filter model suit their own framework. The hosted plans remain a separate decision involving error capacity, performance features and retention; those were not benchmarked.
Honeybadger
Honeybadger’s sensitive-data guide describes request-data filtering and a beforeNotify handler for inspecting or changing notices. We tested an explicit filters list against notice parameters. The result matched the other configured recipes: the named value was removed and free text remained.
The Node transport in this installed version did not pass the custom endpoint’s port through to its HTTP request options. Our harness supplied the loopback receiver port at the HTTP-request boundary; it did not modify report data or SDK filtering code. This adaptation is disclosed because an ordinary custom-endpoint recipe alone did not produce the final capture.
For a team that wants its error notice and request context handled together, inspect both the documented filtering scope and the actual payload. Check plan-specific capacity and retention before purchase. We did not test other Honeybadger telemetry paths.
Methodology and limitations
Toolverly Editorial ran this experiment on October 18, 2026 using Node.js 26.0.0 on macOS and the exact SDK versions in the table. Every final error report reached an HTTP receiver bound to 127.0.0.1; credentials were dummy values, automatic session/error collection was disabled where configured, and the hosted services received no reports. Raw request bodies, package versions, harness code and final marker results were retained.
We did not test hosted ingestion, server-side scrubbing, dashboards, browser integrations, replay, attachments, source maps, regulatory compliance or overall product security. One event per SDK cannot certify a complete privacy policy. AI assistance was used for research, code and writing; actual outputs and source claims were reviewed before publication. Read about Toolverly Editorial.
There is no overall winner in these five equal marker outcomes. The decision is which schema and control surface your team can maintain and verify. Keep free-text secrets out of errors at their source, test your outbound boundary, and preserve enough safe context to diagnose failures. Our log management comparison addresses searchable operational records, while incident management software coordinates the response after a signal reaches people.
Photo by Rob Wingate on Unsplash. Read about our publication or send a correction.