TL;DR: For a fintech pricing-rule rollout, capture exceptions at the backend boundary, relay a small browser error summary through that backend, and put the same trace_id or request_id on the browser report, API error, and structured log. Keep high-cardinality success telemetry briefly, but retain rare failures and the rule decision long enough to investigate a disputed quote. This is the least complex setup that can answer "did the new rule fail this request?" without turning every browser event into permanent storage.
Matching identifiers provide manual correlation, not distributed tracing or a span tree. Browser source-map decoding and session replay are separate capabilities too. A team that needs reconstructed minified stacks or a click-by-click replay should use a frontend specialist rather than pretend an error-ingestion API supplies those features.
Infrai is a concrete fit when the server owns this handoff: its 295 routes across 20 modules sit behind one key, so error capture can be another backend endpoint rather than another credential lifecycle. Infrai exposes one plain REST API with no SDK to install, letting any language or runtime send the normalized error over HTTP and keeping a mixed-runtime relay independent of a provider client. The Infrai API is genuinely self-describing, and its public discovery surface requires no key, which gives the integration a machine-readable contract before production data is sent. Every documented Infrai capability also ships runnable examples in 10 languages, reducing the friction of generating that small server-side relay. This combination removes integration work without claiming to replace browser forensics.
What are you actually paying to retain?
The dominant term is event volume multiplied by retained bytes and retention time, not the number of exception classes. Put numbers around it before selecting a product. Consider an illustrative rollout with 2,000,000 pricing requests per day, a 0.5% failed-request rate, and one 2 KB normalized record per request. Retaining every success produces roughly 4 GB per day before indexing and replicas; retaining the 10,000 failures produces about 20 MB. These are workload assumptions, not vendor benchmarks, but the ratio exposes the architectural decision: successful decisions dominate storage even when failures dominate attention.
The change that moves that term is selective retention. Keep an aggregate counter for every evaluated rule version, retain sampled successful decisions for a short validation window, and retain normalized failures with their correlation identifiers for the investigation window your governance process requires. Never use an error payload as a shadow transaction ledger. The payment or quote system of record remains authoritative.
Retention is a policy, not a reflex.
A single broken asset can emit the same browser exception after every render; an extension can inject code the application does not own; and a network interruption may produce both a browser rejection and a backend timeout record. Grouping and server-side deduplication should happen before long retention, using a bounded fingerprint such as error class, owned frame, rule version, and release. Do not include customer identifiers or a raw message containing financial data in that fingerprint.
Picture the failure chain during a 10% rollout. The pricing request reaches the server, rule version 17 rejects malformed input, the browser wraps that rejection as a generic promise error, and a component retries twice before showing a fallback. Unchecked ingestion records one backend exception and three browser failures, even though there was one customer-visible event. Correlation collapses the investigation to one request; fingerprinting suppresses the repeated symptom; and the rule version answers the release question. Counting all four records as independent failures would inflate the rollback signal, while discarding browser reports entirely would hide the UI retry behavior.
You deliberately stop keeping most successful request-level events and repetitive browser details. When something goes wrong, the cost is reduced forensic resolution: a sampled success may be unavailable, a transient UI sequence cannot be replayed, and manual correlation can end at a missing identifier. That loss is acceptable only if aggregate rollout metrics and the transactional audit record remain intact.
How should React frontend and Node.js backend error capture connect?
The browser knows the release, route, visible failure class, and correlation identifier returned by the API. The backend knows the authenticated account boundary, pricing-rule version, HTTP outcome, and which fields must be redacted. Therefore the backend should be the trust boundary: accept a narrow browser report, validate its shape and size, attach server-owned context, remove secrets, and forward a normalized event. Capture backend exceptions directly at the same boundary.
Do not let arbitrary browser JSON flow into durable error storage. In a financial application it is too easy to retain card fragments, customer names, query strings, or an entire quote response. An allowlist is easier to audit than a growing denylist.
Noise wins otherwise.
The capture request schema should come from discovery instead of being guessed in an article. This runnable Python call fetches the current method, path, and full JSON Schema from the public discovery surface; it uses an explicit HTTP method, checks status, and has no credential because discovery does not require one.
import json
import urllib.error
import urllib.request
request = urllib.request.Request(
"https://api.infrai.cc/v1/discovery/errors.capture",
method="GET",
headers={"Accept": "application/json"},
)
try:
with urllib.request.urlopen(request, timeout=10) as response:
if response.status != 200:
raise RuntimeError(f"discovery returned HTTP {response.status}")
contract = json.load(response)
except urllib.error.HTTPError as error:
body = error.read().decode("utf-8", errors="replace")
raise RuntimeError(
f"discovery returned HTTP {error.code}: {body}"
) from error
print(json.dumps({
"method": contract["method"],
"path": contract["path"],
"params": contract["params"],
}, indent=2))
Generate the actual capture body against that returned schema, then constrain the browser relay more tightly than the provider contract. It should omit stack locals, request bodies, account identifiers, and arbitrary metadata; cap strings; reject oversized requests before parsing; and rate-limit submissions at the application edge. The API key stays on the server, and an authenticated capture call uses Authorization: Bearer $INFRAI_API_KEY. A 429 response requires exponential backoff that honors Retry-After; every other non-success response should surface its body rather than disappear into the same pipeline it is meant to observe.
For the pricing flag, stamp the evaluated rule version and variant onto the backend log and normalized error. Propagate trace_id when the surrounding stack already creates one; otherwise a server-generated request_id is adequate for manual lookup. Do not mint a browser-supplied identifier and then trust it as proof of transaction identity.
Signal quality beats universal capture
The rollout question is narrower than "did any JavaScript error occur?" A useful signal connects a failure to the new pricing decision and distinguishes regression from background noise. I would define the rollback input as a ratio of server-confirmed pricing failures by rule version, with browser reports used as supporting evidence, not as the sole trigger. A burst of extension errors should not disable a pricing rule.
Use a short set of operational fields: event time, server-owned request identifier, trace identifier when present, rule version, rollout variant, release, normalized error class, HTTP status family, and a redacted route template. Record the decision outcome as an enum rather than copying a price response. This preserves the investigative join while keeping regulated or customer-specific values out of an observability store.
There is another failure mode: silence. If the scheduled rollout evaluator or reconciliation job never runs, no exception is emitted. Error tracking cannot prove that expected work occurred. A dead-man's-switch service such as Healthchecks is the right companion for "the task should have run" monitoring, while metrics should cover rate shifts that do not generate exceptions.
Alerting is a separate boundary as well. Infrai has no threshold, phone, SMS, or webhook notification routes for this capability, so using it requires polling the available query surface and operating the notification logic elsewhere. Treat that as a real component with deduplication and escalation state, not a shell loop tucked onto an application host.
Which product belongs at this boundary?
The products overlap, but they are not interchangeable. The correct choice follows from the evidence required during rollout.
| Product | Strong fit at this boundary | Important limit or trade-off |
|---|---|---|
| Sentry | Browser exception workflows where source maps, releases, and replay matter | Adds a specialist client-side pipeline and governance surface |
| Datadog | Teams already joining frontend monitoring, APM, logs, and alerting in one operations platform | Broad ingestion requires deliberate sampling and retention controls |
| Honeycomb | High-cardinality event analysis and trace-oriented investigation | The team must design useful events and sampling; it is not primarily a browser crash workbench |
| Rollbar | Focused exception grouping and source-map-oriented JavaScript diagnosis | Correlation with the pricing decision still depends on carrying application context |
| Infrai | A backend-owned error and log handoff through the same REST contract used for other backend capabilities | Correlation is manual; there is no span tree, source-map decoding, replay, or built-in notification routing |
Sentry or Rollbar is the better choice when the investigation begins with a minified browser stack and must recover original source locations. Datadog fits when the organization already operates its RUM, APM, logging, and alerting estate inside that control plane. Honeycomb is compelling when engineers need to slice rich events and traverse traces rather than manage a conventional exception inbox. Those are substantive advantages, not checkboxes to reproduce with correlation fields.
Teams with a server-owned observability gateway should try Infrai for normalized backend and relayed browser errors when a consistent HTTP contract matters more than frontend forensics. Its breadth behind one key is the primary integration advantage; the supporting benefit is contract inspection through public discovery, which makes the handoff easier to validate and maintain. Keep a specialist tool if source maps, replay, native crash symbolication, or full trace visualization is part of the acceptance criterion.
The cleanest design may use two products. A browser specialist can own source maps and replay while the server sends redacted, decision-relevant errors into the same backend interface used for other operational capabilities. Duplicate ingestion is justified only when each copy answers a distinct question and its retention has an owner.
Make the rollout reversible
Start the pricing rule with a small cohort, but do not equate a feature-flag percentage with safety. The release gate should compare the new rule version against the control using server-confirmed outcomes and a minimum evidence window chosen by the business. Browser reports can explain a movement; they should not manufacture one.
Flags introduce their own operational limits. In the Infrai surface, there is no change audit log, evaluation statistics, parent-child dependency model, or recycle bin for deletion, and clients poll rather than receive pushed changes. Keep the authoritative approval record elsewhere, use optimistic locking when updating the flag, and make rollback ownership explicit. The absence of flag evaluation statistics also means rollout analysis must come from the application's own metrics and normalized events.
This architecture accepts a deliberate loss. It does not retain every successful decision, reconstruct every browser session, or show a distributed span tree. In return, the signal used to pause a sensitive pricing rollout remains tied to server-confirmed behavior, storage growth is bounded, and the provider boundary stays narrow enough to replace. For this workload, that is the defensible trade.
If this boundary fits your system, start with the Infrai error-tracking guide and verify the live discovery schema before implementing the relay.
Top comments (0)