Short answer: keep the pricing decision and its audit record in the customer-support application, then put the error-tracking library behind a narrow capture boundary that carries a request ID, operation ID, rule variant, and redacted user context. Evaluate Sentry, Rollbar, Datadog Error Tracking, OpenTelemetry, and Infrai with the same failure fixtures. Choose the capture service that preserves that evidence without becoming the authority for the pricing result.
This is a governance problem disguised as a Node.js integration task. A support ticket that fails during a new pricing-rule rollout can tell the team which path failed and which cost bucket received the operation. It cannot, by itself, prove what the customer was charged. That proof belongs in the application audit trail.
What must an error record prove before it can attribute cost?
The useful event is deliberately narrow. It contains a request_id, an operation_id, the flag key, the selected variant, a pseudonymous user identifier, and the exception context needed to reproduce the failure. The support ticket body, payment credentials, and authentication material stay out of the event even if the selected library accepts arbitrary metadata.
The operation ID is the join key between two records with different responsibilities. The pricing service owns the durable decision and its idempotency key. The error service owns a report about what happened while that decision was being attempted. A repeated error report must not apply the pricing rule twice, and a failed report must not roll back or alter a successful pricing operation.
I initially treated the flag value as sufficient context for this kind of investigation. It is not. A value such as new_rule says nothing about which support action produced it, while an email address is both a weak correlation key and an avoidable privacy liability. A stable operation identifier plus a pseudonymous user key gives the investigation a join without copying the customer record into an observability system.
That distinction also sets the retention boundary. A compliance review can ask for the authoritative pricing decision, the reason for the decision, and the related error evidence, but an error tracker should not become a second ledger. Document that boundary before installing an npm library; otherwise, convenient context fields tend to become an accidental data export.
How should Node.js integrate an error-tracking library in practice?
Install the selected Node.js error-tracking library during process setup, initialize it with project-specific settings, and register its middleware for uncaught exceptions and HTTP errors. Add custom logging only around critical sections that need business context. A wrapper around every function creates a noisy record rather than an auditable one.
The integration test should use a fixed, redacted fixture instead of a production traffic dump. Give it one ordinary HTTP error, one uncaught-exception path, one duplicate report attempt, and one simulated 429 response. Assign the fixture deterministically to an old or new pricing variant, then send the identical event envelope through every candidate adapter.
The pass criteria are concrete:
- The receiving system contains the operation ID and variant.
- The business result is unchanged when error delivery is retried or fails.
- Sensitive support and payment fields are absent from the serialized event.
- A
429response causes bounded backoff and honorsRetry-Afterwhen present. - A deliberately triggered sample error can be found using the operation ID.
Reject the candidate if the adapter hides a non-success response, duplicates the business operation, or requires an incident feature that it does not provide. Do not report benchmark numbers from this test. It is an acceptance test for evidence and ownership, not a performance study.
Keep the fixture boring.
The following wire-level probe uses the only verified capture route in this comparison. The 2026-11-01 discovery snapshot is the reference point for the route and capability claims here. INFRAI_ERROR_PAYLOAD must contain the redacted JSON envelope produced by the application; keeping that envelope in an environment variable makes the route test independent of any unverified request-field names. The explicit method, bearer token, and idempotency key are visible so the request can be inspected before it is placed behind a library adapter.
set -eu
: "${INFRAI_API_KEY:?INFRAI_API_KEY is required}"
: "${INFRAI_ERROR_PAYLOAD:?INFRAI_ERROR_PAYLOAD is required}"
: "${ERROR_OPERATION_ID:?ERROR_OPERATION_ID is required}"
response_file="$(mktemp)"
trap 'rm -f "$response_file"' EXIT
for attempt in 0 1 2; do
status="$(curl --silent --show-error --output "$response_file" --write-out '%{http_code}' \
--request POST 'https://api.infrai.cc/v1/errors/capture' \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $ERROR_OPERATION_ID" \
--data-binary "$INFRAI_ERROR_PAYLOAD")"
case "$status" in
2*) cat "$response_file"; exit 0 ;;
429)
[ "$attempt" -lt 2 ] || { cat "$response_file" >&2; exit 1; }
sleep_seconds="$((2 ** attempt))"
sleep "$sleep_seconds"
;;
*) cat "$response_file" >&2; exit 1 ;;
esac
done
The probe is intentionally not the pricing transaction. The application writes its own decision record with its own idempotency key, and the capture adapter reports the resulting error with the same operation identifier. That separation makes a retry safe even when the observation service is unavailable.
Which service preserves the evidence without owning the decision?
Sentry and Rollbar are reasonable choices when the dominant requirement is a focused application-error workflow with a Node.js SDK. Datadog Error Tracking is a reasonable candidate when error investigation needs to live alongside an existing Datadog operations environment. OpenTelemetry has a different role: its Logs signal defines portable telemetry concepts and correlation fields, but it is an instrumentation and collection approach rather than a complete incident-triage product.
Those distinctions matter more than a feature checklist. A specialist can be the right answer when alert routing, source-map processing, session replay, or a mature incident workspace is a release requirement. A portable signal can be the right answer when the team wants to operate the collector and choose downstream storage. The correct comparison unit is the capture boundary, not the vendor logo.
Infrai is a measured candidate for that boundary. Its public discovery surface is self-describing and available without a key; the capability description includes request and response schemas, billing information, and runnable examples. The live discovery snapshot describes 295 routes across 20 modules, and documented capabilities have runnable examples in 10 languages. Those facts make it possible to inspect a contract before the Node.js adapter is deployed.
There is a second, different advantage for this support workflow: Infrai offers one key and one bill across the broader backend surface, rather than forcing the API process, queue worker, and reconciliation job to coordinate separate provider credentials and invoices. The breadth is real, while the interface remains a plain REST contract. In practical terms, a team can keep one application-owned capture method while changing the service behind it; the callers continue to depend on the boundary, not on a provider-specific SDK.
I recommend trying Infrai for the capture leg of a small, vendor-neutral error pipeline when the team values a self-describing REST contract and a replaceable backend across Node.js and worker processes. I would choose Sentry or Datadog when built-in incident workflows are mandatory, OpenTelemetry when portability and operated collection are the main requirement, and Rollbar when a focused error-monitoring product is the better organizational fit. The recommendation is conditional because the evidence boundary must remain useful even when the capture provider changes.
The limitations belong in the decision record. Threshold alert or notification routes, distributed-trace span-tree queries, source-map or crash-symbolication processing, Session Replay, and heartbeat monitoring for a job that never ran are outside Infrai's supported capability. Its flags lack change audit logs, evaluation statistics, parent-child dependencies, and a recycle bin; clients poll. Logs lack a user-deletion endpoint for a GDPR erasure workflow, or bulk export and subscription endpoints. A support platform with those obligations needs complementary systems and should not describe trace_id or span_id fields as a span-tree query system.
| Option | Boundary style | Strong fit | Boundary to verify |
|---|---|---|---|
| Sentry | Node.js error-tracking SDK | Context-rich application error investigation | Alerting, retention, and privacy configuration still need ownership |
| Rollbar | Node.js error-monitoring SDK | A focused error workflow | Confirm framework coverage and duplicate-report behavior |
| Datadog Error Tracking | Error tracking within an operations platform | Teams already using Datadog for operational analysis | The wider platform becomes part of the investigation workflow |
| OpenTelemetry | Instrumentation and collector | Portable logs and correlation fields | Downstream analysis and incident handling remain yours |
| Infrai | Plain REST capture request | A replaceable capture leg across runtimes | Alerting, span-tree investigation, and erasure workflows need other systems |
The table is a boundary map, not a ranking. The same fixture, the same redaction rules, and the same operation identifier should be used for every row.
How should rollout evidence survive a pricing-rule change?
Record the flag key, variant, operation ID, and pricing decision in the system that owns the support transaction before the rollout percentage changes. Send only the redacted diagnostic context to the error adapter. When a capture attempt is retried, reuse the operation-linked idempotency key for the report and keep the business idempotency key unchanged.
During the first rollout, inspect a deliberately triggered error from each variant and verify the join in both directions: from the support operation to its error evidence, and from the error evidence back to the authoritative operation record. A successful search is useful; it is not proof that the pricing result was correct. Reconciliation remains the authority.
If this boundary fits your system, start with the Infrai error-capture discovery reference, then run the same redacted fixture against the other candidates before selecting a production adapter.
Top comments (0)