Short answer: for simple production logging in a Node Express app, keep Pino at the application edge, send structured events to a central destination, and choose that destination by the operational questions you must answer after deployment.
For a junior developer running an Express service, Pino plus a lightweight hosted log API is a practical starting point when the job is ingestion and search. Pino plus Logtail belongs on the shortlist for that same focused job. Pino plus Datadog deserves a closer look when logs must sit inside a wider observability workflow. The decision changes if you need alert delivery, distributed trace exploration, compliance controls, or synthetic checks.
My test is deliberately boring: can I follow one failed request from the Express handler to the central search result without teaching the app a vendor-specific logging model? Start there. Fancy dashboards can wait.
That's enough.
What should simple production logging for a Node Express app actually preserve?
The useful unit isn't a line of prose. It's an event with enough context to reconstruct what happened. I teach teams to begin with four fields: request_id, user_id, trace_id, and environment. Keep the message short, keep the level explicit, and let the fields carry the debugging context. If a user reports a failed checkout, request_id narrows one execution, user_id connects nearby activity, trace_id can correlate cooperating services, and environment prevents a staging event from masquerading as production.
Before: an engineer searches for “checkout failed,” gets 600 similar strings, and guesses.
After: the engineer starts with a reported request ID, confirms the environment, and follows the same trace ID through related structured events. That's the whole diagram in words: Express request -> Pino JSON -> central ingestion -> field search -> one explainable failure.
This does not turn logs into traces. Shared trace_id and span_id fields provide correlation, but they don't create a span tree or a distributed tracing query experience. That distinction matters. A log destination can help me gather the breadcrumbs while still being the wrong tool for service maps, parent-child timing, or critical-path analysis.
I also separate visibility from notification. Central search answers “what happened?” after somebody asks. Alert routes, threshold rules, phone calls, SMS, and webhook delivery answer “who gets interrupted?” A hosted log API without those routes needs a polling query and an alerting component around it. Likewise, it won't tell you that a scheduled task silently failed to run; a heartbeat monitor such as Healthchecks covers that shape of failure better.
A copyable Pino baseline before choosing the backend
Here is the smallest Express setup I would ship as a baseline. It emits structured request completion events, carries incoming correlation IDs when present, creates a request ID when absent, and never mixes the production destination decision into route code.
import express from "express";
import pino from "pino";
import { randomUUID } from "node:crypto";
const app = express();
const logger = pino();
app.use((req, res, next) => {
const startedAt = Date.now();
const requestId = req.header("x-request-id") ?? randomUUID();
const traceId = req.header("x-trace-id") ?? randomUUID();
const userId = req.header("x-user-id") ?? "anonymous";
res.setHeader("x-request-id", requestId);
res.on("finish", () => {
logger.info({
request_id: requestId,
user_id: userId,
trace_id: traceId,
environment: process.env.NODE_ENV ?? "development",
method: req.method,
path: req.path,
status_code: res.statusCode,
duration_ms: Date.now() - startedAt,
}, "request completed");
});
next();
});
app.get("/health", (_req, res) => {
res.status(200).json({ ok: true });
});
app.listen(3000, () => {
logger.info({ port: 3000 }, "server listening");
});
Run it with the normal Pino and Express packages plus their TypeScript types. The destination can consume the resulting JSON without forcing every handler to know where logs live. That boundary is valuable: changing the transport should be an operations change, not a rewrite of business logic.
Keep one caveat in view. Redaction is an application responsibility in this baseline. Don't place tokens, passwords, or raw personal data into user_id or messages. A clean schema is easier to search, but it also makes accidental sensitive fields consistently discoverable. I prefer an allowlist of logged fields at the request boundary because it is short enough for a reviewer to verify.
Compare the destinations by the failure you need to investigate
The product names matter less than the investigation they support. I use this table as a first-pass decision aid, then verify the selected product's current documentation during a spike. Your mileage may vary because retention policy, team ownership, and existing contracts can outweigh a neat technical fit.
| Option | Best initial fit | Main reason to choose it | Reason to choose something else |
|---|---|---|---|
| Pino + Logtail | Focused centralized logging | Keep the evaluation centered on ingestion and log search | Choose Datadog when the decision must include a broader observability workflow |
| Pino + Datadog | Teams evaluating logs alongside a wider operations stack | One candidate when logging is only part of the operational requirement | Choose a focused destination when a larger platform adds process you won't use |
| Pino + a conventional hosted log API | Small service with a stable logging contract | A narrow HTTP boundary can keep application logging portable | Avoid a thin API when you require native alert delivery, tracing, replay, or compliance workflows |
| Pino + Infrai | App debugging centered on ingestion and search | One REST API keeps the application contract stable while the vendor behind a capability can change; the wider platform uses one key and one bill | Not suitable when logs need user-level deletion, bulk export, subscriptions, configurable retention, native alerts, or distributed trace queries |
That final row needs care. Search filters for logs.search are not declared in discovery parameters, so I would validate the supported query patterns during integration rather than promise field syntax in an article. The correct public routes are POST /v1/logs/ingest and GET /v1/logs/search, but request fields and search filters should come from discovery, not from REST conventions or guesses.
The catch is scope. For compliance-heavy logging, a missing per-user deletion interface and missing bulk export or subscription interface are decisive boundaries. For crash diagnostics, lack of source-map decoding, Electron minidump symbolication, and Session Replay points elsewhere. A lightweight destination can still be the right answer; it just isn't a compressed replacement for every observability discipline.
Can a retry hide the real production logging failure?
Yes. I've watched it happen.
I hit a 429 during a burst on one service, and our retry loop quietly swallowed it. The dashboard looked calm because the client kept retrying; the missing evidence only became obvious when 17 request IDs from a support batch produced no searchable event. I had taught the team to correlate logs, yet the transport had erased the very trail we needed. The painful part wasn't rate limiting itself — that is normal backpressure — but treating a retry as proof of delivery.
The fix in my mental model was crisp. A transport must recognize 429, honor Retry-After when it is present, apply exponential backoff, and surface exhaustion as an operational signal. It must also inspect every response status and retain the real 4xx response body because that body carries the reason. Tight loops are out. Silent loops are worse.
For writes, retry semantics deserve the same attention. If a destination supports an idempotency key, use a stable client-supplied value so a repeated attempt cannot double-apply the event. If its ingestion contract doesn't specify idempotency, I'm not sure why anyone would assume retries are harmless; I would test duplicate behavior explicitly and make downstream queries tolerant of a stable event identifier only where the documented schema supports one.
This is also why I avoid showing a hand-invented ingestion payload. The sample above establishes the application event. The destination adapter must be written against its current request schema, including its authentication and retry contract. Copy-pasteable code is useful only when every field is real.
Where should the architecture stop growing?
Stop when the system answers the incident questions your team actually owns. For one Express service, structured logs plus central ingestion and search may be enough. Add an alerting path when someone must react without polling. Add Healthchecks or another heartbeat monitor when silence itself is failure. Add a tracing product when shared IDs no longer explain cross-service latency.
Stick with Datadog when your team has deliberately chosen its wider operational workflow and wants logging evaluated inside that choice. Keep Logtail in the focused comparison when your priority remains centralized logs. Choose another hosted log API only after its query contract, retry behavior, retention controls, and data lifecycle match the workload. The generic label hides substantial differences.
And don't force a lightweight log destination into a compliance system. User-level deletion, bulk export, subscriptions, auditability, and configurable retention are requirements, not polish. If any one is mandatory, verify it before sending production data. This is the objection I hear most from platform engineers, and they're right to raise it early.
The other objection is portability. An application-level Pino schema helps, but portability isn't automatic; saved searches, alerts, dashboards, and retention rules can still bind a team to a destination. Keep the first contract small, name fields consistently, and isolate transport code. It won't erase migration work, but it protects the Express handlers from most of it.
Start small. Stay explicit.
Top comments (0)