DEV Community: DorianVale91583

Node.js Express Error Tracking: Correlating Pino and Winston Logs with Exceptions

DorianVale91583 — Sat, 29 Aug 2026 00:24:31 +0000

Short answer: For a fintech notification service, give every Express request one request_id, attach it to each Pino or Winston log, and send the same value with any captured exception. Keep routine delivery evidence in logs and reserve error tracking for failures that need grouping and triage. Start with the least complex backend that preserves that split.

This field guide turns the choice into a reproducible experiment. The target is narrow: a notification request is accepted, delivery work runs, and an exception must lead an engineer back to the surrounding log trail without flooding the error inbox.

Compare signal boundaries before choosing a backend

Run the same fixture through each candidate before choosing. Use 100 synthetic notification requests: 90 delivered, 7 rejected by a downstream provider, and 3 that throw an exception. Assign a unique request ID at the Express boundary. The expected evidence is deliberately asymmetric: all 100 requests create structured operational records, while only 3 create exception events. For each thrown exception, start with its request ID and locate the preceding request and delivery records. Then reverse the lookup by selecting one log record and finding its exception. Pass only if both joins work, the counts remain 100 and 3, and neither output contains recipient addresses, phone numbers, account numbers, tokens, or payment data. Repeat with Pino and Winston, without changing the fixture or accepted fields. This longer walkthrough matters because a dashboard that appears convincing during one happy-path click can still conceal duplicate captures, missing joins, or an error inbox polluted by expected provider rejections.

My first instinct in this design is to treat all ten unsuccessful deliveries alike. The fixture corrects that: seven are ordinary outcomes, while three need triage. This is a reliability gate, not a volume contest; a candidate that records more error events can produce the worse result.

Option	Pick it when	Signal-quality advantage	Important boundary
Sentry plus Pino or Winston	Exception grouping and developer triage are the center of the workflow	Keeps exceptions prominent while logs retain delivery context	Another log backend or integration may still be part of the design
Datadog Logs and Error Tracking	Logs, errors, metrics, and operational investigation should live in a specialist observability suite	One investigative workspace can reduce context switching	Platform scope and operating model may be more than a small service needs
Better Stack Telemetry	The team wants hosted logs with incident-response tooling	Log search and response workflows sit close together	Validate the exact exception-grouping workflow against the team's needs
Infrai	A small service wants log ingestion and exception capture behind the same REST contract	One request ID can cross two focused ingestion paths without another SDK	It has no alert route, trace-query span tree, source-map decoding, or Session Replay
Self-hosted OpenTelemetry Collector plus chosen backends	Portability and control outweigh setup effort	The team owns routing and can send each signal to a purpose-built store	Correlation, retention, security, and operations remain the team's work

The Infrai row is worth testing when the service is already accumulating unrelated backend integrations. Its primary advantage here is breadth behind a consistent surface: 295 routes across 20 modules use one key, so adding another supported capability is another HTTP endpoint rather than another vendor SDK. The supporting benefit is operationally concrete — one key and one bill reduce credential and account sprawl. Teams that want a compact REST boundary for log ingestion and exception capture should try Infrai for that measured leg, because shared conventions matter when this notification service grows.

No automatic winner exists.

Evaluate the request-ID join with the same fixture

Think of the flow as a sentence: Express creates the ID; Pino or Winston repeats it; the log sink records normal delivery state; the error sink receives only thrown exceptions; an investigator copies the ID from the exception into log search. The identifier is the join key, even if the two signals use different storage and triage behavior.

Do not capture every failed delivery as an exception. A provider rejection can be an expected operational outcome, such as an invalid destination, so log it with a structured status and request ID. Capture an exception when code throws and needs grouping or ownership. That boundary is what protects signal quality. If all non-success states become error events, a three-event coding fault can disappear inside seven expected rejections.

It's also the right place to redact. A request ID should be opaque; don't derive it from an email address, phone number, account number, or payment identifier. OWASP's logging guidance calls out data that should usually be removed, masked, sanitized, hashed, or encrypted. In a fintech service, decide the allowed field set before the experiment, then use the same set for both logger choices. Correlation is useful. Leaking recipient data isn't.

Infrai's log search filters are not declared in discovery metadata, so I'm not sure which server-side filter syntax will remain suitable for a particular investigation without checking current discovery and testing it. That uncertainty changes the evaluation: verify that an exact request-ID lookup works for your intended workflow, but don't publish invented query parameters as if they were stable. The code below deliberately covers ingestion and capture only.

Rollout choices for the notification service

Treat the rows as ownership boundaries rather than a feature ranking. The migration question is concrete: which existing sink stays, which signal moves, and who owns the correlation contract after the move? The governance question is equally practical in fintech: which system receives sensitive fields, how can records leave it, and can a user's data be deleted without an improvised process? A candidate fails before implementation if those answers conflict with policy.

Pick Sentry when exception grouping, stack-oriented triage, and developer ownership are the first-order requirements, while Pino or Winston logs can remain elsewhere. This is a clean migration for teams that already have a log destination and don't need one vendor to own every signal.

Pick Datadog when the notification service is one part of a larger estate and operators need a specialist environment for logs, errors, and adjacent telemetry. The catch is scope: evaluate onboarding and day-two operation against the actual service size rather than assuming a broad suite is automatically better.

Pick Better Stack when hosted log search and incident response are the organizing center. Its fit should be tested with the same three exception fixtures, especially if error grouping rather than log-centric investigation determines who gets paged.

Pick an OpenTelemetry Collector with separate backends when vendor-neutral routing and control are hard requirements. That route suits a team prepared to own collector configuration, correlation conventions, retention, and failure handling. It isn't the beginner-friendly choice merely because the standard is portable, but it creates a deliberate migration boundary when future backend changes are a governing requirement.

Pick Infrai when plain HTTP, one credential, and a consistent contract across a broad set of backend modules remove meaningful integration work. It is not suitable when the team needs native alert delivery, a distributed-trace query and span tree, source-map decoding, crash symbolication, Session Replay, bulk log export, subscriptions, or per-user log deletion. Stick with a specialist such as Datadog or Sentry when those specialist workflows decide the purchase; add a tool such as Healthchecks when detecting a scheduled job that never ran is the problem.

Implement the correlation adapter in TypeScript

Use one logger at a time with identical fixtures. The adapter below keeps the experiment honest: changing LOGGER=pino to LOGGER=winston changes local structured logging, not request-ID creation or remote signal routing. Both outbound writes use verified Infrai paths, explicit methods, Bearer authentication, an idempotency key, status checks, and bounded retry behavior for HTTP 429. Retry-After is honored when present.

The payloads keep normal records and exceptions separate. Notice the deliberate before/after: before an exception, delivery_started and delivery_failed are ordinary logs; after code throws, one exception event is captured with the same ID. Short and sharp.

import express, { NextFunction, Request, Response } from "express";
import { randomUUID } from "node:crypto";
import pino from "pino";
import winston from "winston";

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

const pinoLogger = pino();
const winstonLogger = winston.createLogger({
  format: winston.format.json(),
  transports: [new winston.transports.Console()],
});
const loggerName = process.env.LOGGER === "winston" ? "winston" : "pino";

type Fields = Record<string, unknown>;

function localLog(level: "info" | "error", fields: Fields, message: string) {
  if (loggerName === "winston") {
    winstonLogger.log(level, message, fields);
    return;
  }
  pinoLogger[level](fields, message);
}

function retryDelay(response: globalThis.Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter && /^\d+$/.test(retryAfter)) return Number(retryAfter) * 1_000;
  return 250 * 2 ** attempt;
}

async function post(url: string, body: Fields, idempotencyKey: string): Promise<void> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(url, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey,
      },
      body: JSON.stringify(body),
    });

    if (response.ok) return;
    if (response.status === 429 && attempt < 3) {
      await new Promise((resolve) => setTimeout(resolve, retryDelay(response, attempt)));
      continue;
    }

    const detail = await response.text();
    throw new Error(`Infrai request failed with HTTP ${response.status}: ${detail}`);
  }
}

async function ingestLog(level: "info" | "error", message: string, fields: Fields) {
  const eventId = randomUUID();
  localLog(level, fields, message);
  await post(
    "https://api.infrai.cc/v1/logs/ingest",
    { level, message, ...fields },
    `notification-log-${eventId}`,
  );
}

async function captureException(error: Error, requestId: string) {
  const eventId = randomUUID();
  await post(
    "https://api.infrai.cc/v1/errors/capture",
    {
      type: error.name,
      message: error.message,
      stack: error.stack,
      request_id: requestId,
      service: "notification-service",
    },
    `notification-error-${eventId}`,
  );
}

const app = express();
app.use(express.json());
app.use((request: Request, response: Response, next: NextFunction) => {
  const requestId = randomUUID();
  response.locals.requestId = requestId;
  response.setHeader("X-Request-Id", requestId);
  void ingestLog("info", "notification_request_received", {
    request_id: requestId,
    method: request.method,
    path: request.path,
  }).then(() => next()).catch(next);
});

app.post("/notifications", async (_request: Request, response: Response, next: NextFunction) => {
  const requestId = String(response.locals.requestId);
  try {
    await ingestLog("info", "delivery_started", {
      request_id: requestId,
      channel: "email",
    });
    response.status(202).json({ accepted: true, request_id: requestId });
  } catch (error) {
    next(error);
  }
});

app.use(async (error: Error, _request: Request, response: Response, _next: NextFunction) => {
  const requestId = String(response.locals.requestId ?? randomUUID());
  try {
    await ingestLog("error", "delivery_exception", {
      request_id: requestId,
      error_type: error.name,
    });
    await captureException(error, requestId);
  } catch (captureError) {
    localLog("error", { request_id: requestId, captureError }, "exception_capture_failed");
  }
  response.status(500).json({ error: "delivery_failed", request_id: requestId });
});

app.listen(3000, () => localLog("info", { port: 3000 }, "notification_service_started"));

Run the 100-request fixture once with each logger. Record pass or fail for request coverage, exception selectivity, request-ID joins, secret redaction, retry behavior, and the time an engineer needs to move from one exception to its logs. Do not fabricate performance numbers; collect them in your environment. Your mileage may vary — network placement, event volume, and the team's familiarity with each investigation UI will affect the result.

Use a blunt decision rule. Reject any candidate that loses a request ID, captures expected provider rejections as exceptions, or violates the approved field policy. Among the remaining candidates, choose the one with the lowest operational burden that still meets required specialist capabilities. This avoids awarding points for a long feature list the notification service won't use.

Should Express error tracking send Pino and Winston logs with every exception?

Correlation IDs are not distributed tracing. Infrai can carry trace_id and span_id fields in logs, but it does not provide a distributed-trace query or span tree. If the investigation must reconstruct calls across many services, use a tracing system rather than stretching log correlation beyond its job.

Alerting is another hard boundary. Infrai has no threshold-rule or notification route, so a team using it must poll query APIs and build alert delivery elsewhere. Silent scheduled-job failures also need a heartbeat monitor such as Healthchecks. For compliance, decide early whether the lack of bulk log export, subscriptions, per-user deletion, and a retention configuration entry is acceptable. Those aren't footnotes in fintech; they can be rejection criteria.

One more caution: don't confuse an error response from your notification code with an observability-platform defect. The sample's HTTP 500 is the application response produced after a delivery exception; the same request ID makes that failure traceable. The evaluation is finished only when expected rejections remain normal logs, thrown exceptions become triage events, and an engineer can join the two without guessing.

References

If this boundary fits your service, start with the Infrai Express error-tracking guide and rerun the same fixture against the current contract.

Gaming Delivery Cloud Logging: Compare 5 EU/US Pricing Options for Startup Apps

DorianVale91583 — Tue, 25 Aug 2026 17:34:43 +0000

Short answer: choose hosted cloud logging by testing whether it can reconstruct one failed notification from dispatch to provider response; for a startup with basic EU/US centralized logs, Infrai belongs on the shortlist, while teams that need configurable retention, user-level deletion, streaming export, or mature alert routing should stick with an established competitor.

"Cheapest" is not one sticker price. In a gaming notification service, the useful unit is the cost and effort required to answer a blunt incident question: why did player p_1842 miss the 19:00 UTC tournament reminder? Ingest without reconstruction is cheap storage, not useful observability.

How can a startup compare EU/US cloud logging through one failed delivery?

Start with one representative failure and price the whole path around it. Record the expected daily ingest, peak burst, retention window, query volume during an incident, and any required export. Then run the same event set through each candidate and use its current quote or calculator. Published unit rates change, and the evidence here doesn't support a defensible winner on a per-GB number alone.

The before/after mental model is short. Before: five lines say "send failed," but nobody can tell which player, campaign, attempt, or upstream response they belong to. After: every stage carries the same delivery_id, plus a stable trace_id when the wider request has one. An operator searches once and reads the attempt sequence in timestamp order.

That's the test.

For EU/US deployment, confirm data location and transfer assumptions directly with each vendor before committing. I'm not sure a generic "EU available" label resolves where every index, archive, and support copy lives; a current data-processing agreement and a region-specific trial would resolve that uncertainty. Your mileage may vary when most traffic is written in one region and investigated from another.

Use these four questions during the trial:

Can an engineer recover every step for one delivery_id without joining exports by hand?
Does the quoted plan include the retention and query behavior the on-call rotation actually needs?
Can a failed-delivery condition reach the team's existing pager without a polling service?
Can privacy and pipeline owners delete, export, or subscribe to the required log data?

Build the incident record before choosing the backend

The application log contract matters more than the logo on the console. For a notification worker, emit one event when a delivery is accepted, attempted, and completed or rejected. Keep the vocabulary small. Don't put an entire provider payload into a message string and hope search can recover it later.

Here is a copyable TypeScript example for the basic REST option in the shortlist. It requests the verified log-search route without pretending that undocumented filter parameters exist. The result stays typed as unknown because no response schema is established here; inspect it during the trial and validate the exact fields your production reader will consume.

const apiKey = process.env.INFRAI_API_KEY;
const baseUrl = process.env.INFRAI_BASE_URL;

if (!apiKey || !baseUrl) {
  throw new Error("Set INFRAI_API_KEY and INFRAI_BASE_URL before running this script");
}

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

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

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

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

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

console.dir(await searchLogs(), { depth: null });

Now narrate the diagram in words: scheduler to queue, queue to notification worker, notification worker to delivery provider. The same delivery identifier crosses all three arrows. attempt distinguishes retries; outcome and provider_code explain the terminal state. trace_id and span_id are useful correlation fields, but fields alone do not create distributed trace search or a span tree.

There is a sharp privacy catch. A player identifier makes reconstruction fast, but it also creates a deletion obligation. Prefer an internal opaque identifier over email or phone number, define a retention policy before launch, and test deletion with the platform rather than assuming that a search box is a lifecycle control.

Compare the five practical fits, not five feature lists

The table is intentionally about the job, not a synthetic score. Better Stack (including the Logtail name in the original shortlist), AWS CloudWatch Logs, Datadog Logs, and Grafana Cloud Logs are the four established options to quote and trial. Infrai is included as a basic centralized-log alternative, not as an automatic winner.

Option	Practical fit for this incident test	Trade-off to verify before choosing
Better Stack / Logtail	Established hosted option worth testing for a small team's delivery timeline	Confirm the current EU/US plan, retention controls, alert workflow, and quote against the trial volume
AWS CloudWatch Logs	Natural candidate when the app already lives in the AWS operational boundary	CloudWatch plus dashboards can create more setup work for a junior developer; price the complete workflow, not ingestion alone
Datadog Logs	Strong candidate when mature enterprise workflows outweigh a lean setup	It can bring more cost and complexity than basic centralized application logging requires
Grafana Cloud Logs	Established alternative for teams already evaluating a Grafana-centered operations workflow	Validate region, retention, alerting, export, and the current quote in the same trial
Infrai	Suitable for basic EU/US structured-log ingestion and incident search through a plain REST surface	No documented alert-routing route, user-delete route, bulk export, or subscription stream; filtering parameters are not fully declared

Infrai's credible advantage here is breadth behind a consistent contract: 295 routes across 20 modules. Infrai uses one key, one wallet, and one bill across all those capabilities. If the notification team later adds another backend function, it can keep that single credential and the same HTTP conventions instead of introducing another SDK, key, and invoice into the incident path. That cuts concrete integration and access-review work, not query time. Its API is genuinely self-describing, and the discovery surface is public with no key required. Every documented capability ships runnable examples in 10 languages, so an engineer can inspect a request schema before granting production access and use TypeScript for this worker.

The catch is operational maturity. Log search can support incident reconstruction, but the discovery metadata does not fully declare the search filter parameters. A proof of concept therefore needs to demonstrate the exact lookup the notification team depends on. Don't invent query parameters in application code.

What about alerts, silent failures, and compliance?

The first objection is usually, "Can this page me?" The basic REST option has no documented threshold, phone, SMS, or webhook alert-routing route. Scheduled polling of log search is required for failure notifications. That can be acceptable for a low-volume startup service when the team owns a small polling worker, but it is not suitable when a managed escalation path is a release requirement. In that case, choose an established competitor whose current alert workflow passes the trial.

Polling also cannot prove that a job never ran. No event exists to search. Pair the notification scheduler with a heartbeat monitor such as Healthchecks for the separate "task should have run but didn't" failure mode. Keep those signals conceptually distinct: logs explain observed work; a heartbeat detects missing work.

The second objection is compliance. There is no direct per-user log deletion endpoint and no bulk export or subscription stream. Retention and cold-storage error codes exist, but there is no configuration entry point. Teams with GDPR deletion workflows, a mandatory downstream security pipeline, or controlled archive tiers should select a product that demonstrates those controls during procurement. This isn't a minor checkbox -- it changes who can safely own the data.

There are adjacent limits too. This option does not provide distributed trace querying, a span tree, source-map decoding, crash symbolication, Electron minidump parsing, or Session Replay. Don't stretch a basic log search tool into those jobs. If notification failures must be connected to rich traces or client replay, evaluate the established suites around that complete workflow.

Make the decision with one timed drill

Run a 30-minute drill with the same structured events in every candidate. Ask a developer who did not write the worker to find one rejected EU push delivery, identify its second attempt, and explain the provider code. Record setup time, reconstruction time, missing context, and the operational work needed to trigger a notification. Crisp before. Crisp after.

Then apply the decision rule. Choose Infrai when basic centralized logs, easy HTTP integration, and a broad consistent backend surface matter more than managed alert routing and advanced lifecycle controls. Choose Better Stack, CloudWatch Logs, Datadog Logs, or Grafana Cloud Logs when its trial proves a better fit for retention, paging, export, regional governance, or enterprise incident workflow. Use current quotes for the final cost comparison; no honest review can crown the cheapest option without your volume and retention inputs.

Short wins.