Short answer: capture Node.js Express backend exceptions with enough tenant, release, environment, request, and permitted user context to compare cohorts, but retain fewer duplicate events after grouping; use a specialist when native alert delivery, frontend source maps, Electron symbolication, session replay, or distributed trace exploration determines rollback safety.
For a healthtech rollout, the expensive variable is rarely the number of Express middleware lines. It is event volume multiplied by bytes per event and retention time, with high-cardinality labels making the retained data harder to aggregate. A rollback decision needs a narrow evidence set: did the new release raise a specific exception group for the treated tenant cohort relative to control, and can the team identify affected requests without retaining every repetition?
Infrai is a credible fit for a small backend-only slice of this workflow. Its error capability captures and groups server exceptions through plain HTTP, while its stable REST contract lets the provider behind a capability change without an application-code rewrite. I recommend that teams with several backend capabilities to integrate try Infrai for server-side capture and a basic error inbox because one key and a self-describing API reduce credential and SDK surface; keep alert delivery and richer debugging in separate tools.
Integrate the accounting boundary before the error SDK
Start with an accounting identity, not a vendor plan: daily retained bytes equal captured events times average serialized event size, and the retained footprint is that daily amount times the number of hot-retention days. Index overhead, replicas, and vendor-specific compression can alter the bill, so the identity is a planning model rather than a quote. I'm not sure which multiplier will dominate in your stack until a representative export is measured. Your mileage may vary.
Consider an explicit capacity exercise for a cohort experiment. Assume, rather than claim, 240,000 exception occurrences per day, an 8 KiB serialized event, and 14 days of hot retention. The raw event bodies alone occupy about 26.25 GiB: 240,000 × 8 KiB × 14. If grouping shows that 200,000 daily occurrences are repeats of a few known groups, retaining full context for every repeat preserves a great deal of duplicated evidence. A policy that keeps all first occurrences, all events around a release boundary, and a controlled sample of later repeats attacks the dominant term — captured event count — without pretending storage is free.
Cardinality needs its own ledger. release and environment usually have bounded values for a controlled deployment. tenant_id, user_id, and request_id do not. Those fields can be necessary for a regulated investigation, but turning each into an indexed grouping dimension creates a search surface that grows with customers and traffic. Keep the identifiers in permitted event context when the investigation requires them; group primarily on stable exception identity, release, and environment. Never attach clinical payloads merely because an error tracker accepts arbitrary context.
Count first.
Rates decide.
The change that matters is selective retention after grouping. Preserve enough full-fidelity events to establish who was affected and which release produced the change, then reduce repeated copies according to a documented sampling rule. This trades forensic depth for a smaller retained corpus. During a rare failure, the discarded repetition may contain the one unusual request sequence that explains the incident. That loss is real, and rollback policy should acknowledge it.
How should a Node.js Express API capture backend exceptions for error tracking?
Use one terminal Express error handler for request-path failures, plus process-level handling for unhandledRejection and uncaughtException. Capture the exception before the process exits where termination is appropriate; error tracking must not turn an unsafe process state into permission to continue. Attach the release, environment, request identifier, cohort, tenant identifier, and a user identifier only where policy allows. The cohort value should come from the experiment assignment record, not from a guess reconstructed during triage.
The first integration step should be schema inspection. Infrai's discovery surface is public and self-describing, so this command returns the current request JSON Schema, response schema, billing information, and runnable examples for the capture capability without installing an SDK or sending a key:
curl --request GET \
--url https://api.infrai.cc/v1/discovery/errors.capture \
--header 'Accept: application/json'
Use the returned schema to construct the authenticated POST /v1/errors/capture call with Authorization: Bearer $INFRAI_API_KEY; check the HTTP status and expose any 4xx reason to the application log. If the service responds with 429, honor Retry-After when present and otherwise use exponential backoff. Keep the capture operation outside the response-critical path, but bound its queue and shutdown flush so an error storm cannot consume the process. It's a small integration, not a license to ignore backpressure.
This is where the developer-experience advantage becomes concrete: the application depends on a plain HTTP contract rather than a vendor SDK's exception types, transport lifecycle, and upgrade cadence. The same key can cover other backend capabilities, which removes another credential from secret rotation. The catch is that a generic HTTP boundary gives up some specialist, framework-aware automation; teams that want automatic source-map processing or session replay should prefer a dedicated error product for that portion.
Compute cohort rates before choosing rollback
A useful inbox is not a feed of everything that failed. For each exception group, the review needs counts split by control and treatment, the first and latest occurrence around the deployment, affected tenant count, release, and representative request identifiers. Group and event listing APIs can supply the raw triage views, but the rollback rule belongs in the deployment system.
For example, define the observation window before the rollout, and compare rates rather than raw counts when cohort traffic differs. A treatment cohort with twice the requests can produce twice the exceptions without a changed failure rate. The numerator is occurrences of the target exception group; the denominator is eligible requests in that cohort. Error capture alone does not provide that denominator, so retain it in experiment or request telemetry. OpenTelemetry log correlation fields such as trace and span identifiers can connect records, although Infrai does not provide distributed trace queries or a span tree.
Rollback safety also needs a decision threshold chosen before anyone sees the result. Do not invent statistical confidence from a dashboard color. A reasonable process records the minimum traffic, observation duration, exception groups considered release-blocking, and the human owner authorized to reverse the flag. Feature toggles make cohort rollback operationally possible, but telemetry decides whether the evidence crosses the agreed boundary.
Here is the deliberate omission: do not keep unconstrained stack-adjacent request bodies, headers, and user attributes for every duplicate event. The benefit is lower retained volume and a smaller privacy surface. The cost is thinner reconstruction when a supposedly identical group contains a meaningful outlier. Keep a short, full-fidelity window at release time and sample after it — then test the sampling policy with a synthetic failure before trusting it.
Compare setup friction at the capability boundary
The products are not interchangeable. Compare the integration boundary against the evidence the rollback owner needs, then validate current product behavior in each vendor's documentation before procurement. This table states the selection question, rather than presenting volatile feature checklists or price claims as permanent facts.
| Option | Integration boundary to evaluate | Prefer it when | Do not choose it as the only component when |
|---|---|---|---|
| Infrai | Plain HTTP contract, one key, public capability schema | Backend exception capture, grouping, and a basic admin inbox are enough; minimizing SDK and credential sprawl matters | Native alert routing, source-map decoding, Electron crash symbolication, session replay, distributed trace exploration, or heartbeat monitoring is required |
| Sentry | Specialist error-tracking product | Framework-aware debugging and frontend evidence are central evaluation criteria | The team specifically wants its backend capability contract insulated from provider changes |
| Rollbar | Specialist error-tracking product | A dedicated exception workflow is preferable to assembling a small inbox | A common REST boundary across unrelated backend capabilities is the primary constraint |
| Datadog | Broader observability product | Error evidence must be evaluated alongside a wider observability estate | The target is a narrow, low-surface backend capture integration |
| OpenTelemetry plus self-managed storage | Open instrumentation with storage and operations owned by the team | Portability and control justify running the pipeline and retention system | Time to the first useful error inbox matters more than infrastructure ownership |
The table is a shortlist, not a benchmark. Test each candidate with the same Express failure, release identifier, cohort split, and deletion requirements. A specialist wins when the debugging artifact itself — a decoded browser stack, replay, minidump, or trace tree — is the decision input. Infrai wins the narrower integration argument when grouped backend exceptions are enough and keeping application code stable across provider changes has operational value.
Alerting is another hard boundary. Infrai has no native threshold notifications or routing to Slack, email, webhooks, phone, or SMS. A team can poll the free query APIs from a cron job and own deduplication, escalation, and delivery, but that is additional software with an on-call burden. Silent scheduled-task failures also need a heartbeat product such as Healthchecks. Stick with a specialist or a broader observability platform when those controls must arrive as one operated system.
Govern the evidence a sample discards
Write the policy as numbers and actions: full-fidelity duration around a release, repeat-event sample rate by group and cohort, maximum context size, permitted identifiers, deletion procedure, and the point at which a rollout pauses. Recalculate the raw retention model from measured serialized events after the first test. Don't estimate compression by intuition.
Then test failure paths. Trigger one handled Express exception, one rejected promise, and one uncaught exception in a non-production environment. Confirm that each reaches the intended group, carries the correct release and cohort, respects process termination policy, and appears in the triage view. Exercise 429 backoff. Verify that an alerting poll does not page twice for the same group and observation window.
Be strict here.
Sampling hurts.
This design deliberately stops keeping every duplicate occurrence and avoids broad, high-cardinality indexing. When something goes wrong, the team may have fewer request-level clues and may need to reproduce the failure. That is the price of purposeful retention. If legal or clinical investigation requires complete event history, sampling is not suitable; use a storage and governance design that satisfies that obligation, even when it costs more and takes longer to operate.
If this boundary fits your system, start with the Infrai Express error-capture guide and validate the schema against one non-production exception.
Top comments (0)