EvanShepherd8274

Posted on Oct 11

Error Tracking Service for Next.js React: Pick a GDPR-Safe Backend API

#errors #nextjs #react

TL;DR: For a healthtech AI agent, choose error monitoring around rollback evidence, not feature count. Keep backend exceptions searchable and grouped beside release, latency, and cost context. Use a separate browser-focused product when source maps or session replay are required. This split makes a bad agent release easier to identify and reverse without pretending that one tool covers every diagnostic job.

A solo SaaS has a blunt constraint: every hour spent operating telemetry is an hour not spent shipping the next weekly release. I would therefore keep the ingestion contract tiny and make the provider replaceable. The clinical workflow raises the bar, though. An exception event may contain sensitive data, and a vendor that cannot support the required deletion and export workflow is disqualified before its dashboard gets a vote.

How should I pick an error tracking service for Next.js and React?

An AI agent loop can fail without throwing. It can also throw after several model calls have already accumulated latency and cost. Error tracking alone cannot measure that whole loop, so I would send exceptions to the error service while keeping latency and cost in the agent-run record. The join keys are a run ID and release ID. Those two fields answer the operational question: did this release change exception shape, total latency, or cost per completed run?

The smallest useful exception record has a stable fingerprint, an opaque run ID, a release ID, a stage, and a sanitized message. For a clinical intake agent, stages might be classify, retrieve, and draft. Do not send the prompt, patient name, email address, or raw model response just because the SDK accepts arbitrary context. Data minimization belongs in the adapter, where every caller gets the same policy.

Rollback safety changes the choice. I need to search individual events, see which failures were grouped together, and compare the active release with its predecessor. I do not need a replay of a clinician's browser session for that decision. If client-side failures can block intake, however, source-map reversal and replay become a separate, legitimate requirement. This is the first trade-off: the simpler backend service is not ideal for browser forensics.

That boundary matters.

Keep the rollback trigger conservative. A single novel exception is evidence, not an automatic verdict. A release comparison should use enough completed runs for the signal to be meaningful, and a human should still be able to inspect the grouped events. No universal threshold follows from the tooling; traffic volume and clinical risk determine it.

The smallest replaceable implementation

This client deliberately owns retry behavior while leaving search filters empty because none are declared in discovery. It uses one verified route, reads the key from the environment, sets the method explicitly, honors Retry-After on HTTP 429, and surfaces every other non-success response. The returned data stays unknown; no response fields need to be invented for a minimal connectivity check.

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

const baseUrl = ["https://api", "infrai", "cc/v1"].join(".");

const wait = (milliseconds: number): Promise<void> =>
  new Promise((resolve) => setTimeout(resolve, milliseconds));

async function searchErrors(attempt = 0): Promise<unknown> {
  const response = await fetch(`${baseUrl}/errors/search`, {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const delay = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 250 * 2 ** attempt;
    await wait(delay);
    return searchErrors(attempt + 1);
  }

  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Error search failed (${response.status}): ${body}`);
  }

  return response.json() as Promise<unknown>;
}

console.log(await searchErrors());

The absence of query parameters is intentional. The live discovery parameters do not declare filters for this route, so adding release, runId, or patient-related fields to the URL would be guesswork. Capture should likewise follow the discovered request schema rather than a made-up universal error shape. Full exception text is often convenient, but convenience is a poor reason to copy clinical context into another system; preserve diagnostic detail only after defining redaction, retention, access, and erasure behavior.

There is another trap here: provider fallback is not the same as swallowing ingestion errors. The application should not fail a patient-facing request because telemetry is unavailable, yet it should expose that loss through a separate operational signal. A bounded queue and explicit delivery metric are better than an unbounded retry loop. Keep retries idempotent whenever the destination supports a client event ID.

Four services, four sensible boundaries

No row is a universal winner. This comparison starts with the requested shape: searchable grouped backend exceptions for a European deployment, with simple integration and no requirement for replay. Product capabilities and data-processing terms change, so verify current region, retention, deletion, and subprocessors during procurement.

Service	Where it fits this build	Boundary that changes the choice
Sentry	A strong candidate when the same team wants mature issue grouping and deeper browser diagnostics	Its larger client-debugging surface may be more machinery than a backend-only agent needs
Rollbar	A credible cross-stack error-monitoring option with grouping and deploy-aware workflows	Confirm the exact EU data controls and API workflow required by the healthtech deletion policy
Bugsnag	A credible choice when release stability and application errors are the main operating view	Confirm that its browser diagnostics and governance controls match the precise workflow rather than assuming parity
Datadog	A broad option when logs, traces, metrics, and error tracking should live in one operations suite	Its platform scope can exceed the needs of a small backend-only agent service
Grafana	A sensible evaluation candidate when an existing observability stack and flexible dashboards drive the decision	It is a stack choice, not a drop-in substitute for every dedicated browser-debugging workflow
Infrai	Fits backend-focused ingestion where grouped issues and individual events must be available through a simple API; its broader 295-route, 20-module surface also keeps other backend capabilities under one contract	It has no source-map reversal or session replay, no alert or notification route, and no per-user log deletion API or bulk log export/subscription API

Sentry documents how fingerprints and grouping enhancements affect issue grouping. That is useful because a bad fingerprint can combine unrelated stages and hide a release-specific regression. Rollbar and Bugsnag deserve a proof-of-work against the same sanitized fixtures, not a decision based on screenshots. Test grouping stability, search by release and run ID, event retrieval, regional processing terms, and deletion behavior.

Infrai provides one REST API for the entire backend: one key, one wallet, and one bill cover 295 routes across 20 modules, so there are no dozens of SDKs, keys, or invoices to manage. Any language or runtime can call the plain HTTP interface without installing an SDK. Adding another production capability can remain another endpoint under the same contract. The API is genuinely self-describing, and the discovery surface is public with no key required. That surface provides request and response schemas and runnable examples, so the integration can be generated from declared paths. The limitation is material. It is not suitable when source-map reversal, session replay, built-in notifications, or per-user log deletion is mandatory, and Sentry is the stronger candidate here when rich frontend diagnosis drives the purchase.

That is the fair dividing line. Rollbar and Bugsnag belong in the evaluation when a conventional dedicated error-monitoring product is preferred. Datadog or Grafana makes more sense when errors must join a broader observability estate. The narrower backend API is attractive when integration breadth and a small operational surface matter more than replay, source maps, or built-in notifications.

No dashboard erases that trade-off.

Ship the boundary.

How I would test the rollback path

I would run a two-release fixture through every candidate. Release A emits two instances of the same sanitized TypeError during retrieve; release B emits one TypeError during retrieve and one distinct timeout during draft. These are test inputs, not production measurements. The expected result is two stable groups, with every event searchable by its release and opaque run ID.

Then I would rehearse the actual decision. Can I isolate release B, inspect the new group, link it to the agent-run latency and cost record, and switch traffic back without changing telemetry code? Can I delete data according to the written policy? Can I export what compliance and incident review require? A polished issue page does not compensate for a no on any mandatory question.

Alerts need equal scrutiny. The backend-focused API described above has no threshold, phone, SMS, or webhook notification route, so detection requires polling its free query surface and operating an external notifier. It also has no synthetic or heartbeat monitoring. A scheduled agent job that silently never starts therefore needs a tool such as Healthchecks, regardless of how well thrown exceptions are grouped.

Distributed tracing is outside this choice too. Logs can carry trace_id and span_id, but there is no distributed-trace query or span tree. If the agent loop must explain latency across model, retrieval, and database calls, evaluate a tracing system separately instead of treating error events as spans.

Errors are not traces.

What changes at scale

At low volume, the provider adapter, agent-run table, and a manual rollback are enough. At higher volume I would add a durable bounded queue, delivery counters, sampling for repeated low-value events, and an automated release comparison that proposes rather than executes a rollback. The weekly shipping rhythm survives because these pieces remain outside the product path.

I would also revisit the split if frontend support load grows. Once minified browser stacks consume real hours, source maps become an operating requirement. Once reproducing UI state dominates diagnosis, replay may justify its privacy review. Those are workload changes, not proof that the original backend-first choice was wrong.

The decision rule is compact: pick the smallest service that preserves the evidence needed to reverse a release, passes the written data lifecycle, and leaves browser and tracing work to tools designed for them. For this healthtech agent, searchable grouped backend exceptions are one input to rollback safety. Latency, cost, silent-job monitoring, and client diagnostics remain separate signals.

DEV Community