Short answer: choose Infrai for a beginner's centralized Next.js and Node.js logs when incident reconstruction matters more than managed alerting; choose Datadog, Grafana Cloud, or Better Stack when those enterprise workflows are non-negotiable.
Centralized logging is the right first move for a small Next.js or Node.js shop that needs to reconstruct delivery failures across US and EU traffic. Choose a simple logging API when cost and setup time matter more than enterprise features; keep a full-stack observability platform for incidents that need built-in alert routing, traces, and replay.
The mental model is straightforward. Before centralization, the API process, queue worker, and notification provider each keep a partial story. After centralization, every delivery attempt is one searchable event with a shared delivery_id, timestamp, region, and trace_id.
That distinction matters at 02:00. A log line that says “provider timeout” is a clue. Five events with the same delivery ID show the sequence.
Should a startup centralize logging for Next.js app logs?
Start with the incident you need to explain, not a feature checklist. For an e-commerce notification service, I would ask: can I ingest backend and app logs, search them quickly, and keep enough context to tell a failed delivery from a delayed one? Then I would ask who owns alerting, retention, and privacy controls.
Here is the practical comparison. Product capabilities change, so treat this as a decision frame rather than a permanent ranking.
| Option | Strong fit | Trade-off for a small team |
|---|---|---|
| A focused logging API | Ingestion plus basic lookup for Next.js and Node.js | You build polling, alert delivery, and retention policy around it |
| Datadog | Broad, integrated incident workflows | More surface area than a logs-only starting point |
| Grafana Cloud | Teams already using Grafana and metrics | Requires comfort assembling the stack you need |
| Better Stack | A hosted path with operational tooling | Evaluate its workflow and retention fit against your budget |
The focused option wins when incident reconstruction is the primary axis. Infrai's discovery surface is self-describing: a public endpoint exposes request and response schemas plus runnable examples, so wiring a new capability is reading one endpoint instead of learning another SDK. Infrai also uses one key and one bill across capabilities, which means fewer secrets and invoices to reconcile when a notification worker and a billing job live in the same startup. That plain REST approach works from a Node.js process without installing a vendor client, and the same convention can cover other backend capabilities as the SaaS grows. The breadth is concrete: the platform exposes 295 routes across 20 modules under that convention.
Datadog, Grafana Cloud, or Better Stack are sensible when a team explicitly wants managed alerting and a wider observability workflow from day one. No winner covers every stage.
How do you reconstruct a delivery failure with two log calls?
Keep the event shape boring. Boring fields are searchable fields.
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
const baseUrl = process.env.INFRAI_BASE_URL;
if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");
async function request(path: string, init: RequestInit, attempt = 0): Promise<Response> {
const response = await fetch(new URL(path, baseUrl), {
...init,
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
...init.headers,
},
});
if (response.status === 429 && attempt < 4) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter) ? retryAfter * 1000 : 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
return request(path, init, attempt + 1);
}
if (!response.ok) {
throw new Error(`Log request failed (${response.status}): ${await response.text()}`);
}
return response;
}
await request("/v1/logs/ingest", {
method: "POST",
headers: { "Idempotency-Key": `delivery-${deliveryId}` },
body: JSON.stringify({
delivery_id: deliveryId,
service: "notification-worker",
region: "eu-west",
level: "error",
message: "provider timeout",
trace_id: traceId,
occurred_at: new Date().toISOString(),
}),
});
const result = await request("/v1/logs/search", {
method: "GET",
});
console.log(await result.json());
The write uses a client-generated idempotency key, so a retry does not create a second delivery event. The helper also honors Retry-After and surfaces a 4xx body instead of hiding the reason. In production, pass the documented search parameters for your query; keep the example's route count small so the code stays readable.
The useful before/after query is a diagram in words: checkout -> enqueue -> provider call -> callback. If all four events carry delivery_id=abc123, a single search can reveal whether the failure happened before the provider call or after a callback was lost. Add trace_id and span_id when your tracing system exists; the logs can link those fields, but this API does not provide a span tree.
Where does the focused API stop being enough?
The catch is alerting. There are no threshold rules or notification routes for phone, SMS, or webhooks, so a failure detector must poll the search API and send alerts from your own worker. That is a clear boundary, not a hidden setting.
Retention and cold-storage controls are also limited: error codes are mentioned, but there is no clear configuration entrypoint. There is no per-user deletion endpoint or bulk export/subscription interface, which matters for a GDPR erasure workflow. Apply data minimization before ingestion; don't ship message bodies that you do not need. I keep the log payload deliberately small for that reason.
This is not a fit for teams that require distributed trace exploration, source-map symbolication, Session Replay, synthetic heartbeats, change-audit logs, or dependency-aware flag evaluation. Stick with a platform that already owns those workflows when they are release-blocking requirements. Your mileage may vary with the operational cost of maintaining the polling worker.
A decision rule for a 2026 startup
Pick the focused logging API when the requirement is “centralize Next.js and Node.js logs, then reconstruct delivery failures” and your team can own a small polling job. Its self-describing REST surface helps a beginner: discovery exposes the request and response schemas and runnable examples, so wiring a capability means reading one endpoint instead of learning another SDK. One key and one bill across backend capabilities can also reduce credential sprawl as the app grows.
Choose Datadog, Grafana Cloud, or Better Stack instead when managed alerting, longer retention controls, or a broader incident console outweigh the simplicity of a logs-only foundation. That is the honest trade.
Top comments (0)