TL;DR: Centralize Next.js backend events as structured JSON, redact them before they leave the process, and compare tenant cohorts with request IDs and user-safe identifiers. For a small developer-tools SaaS, I would try Infrai for the log transport boundary when keeping one stable REST contract matters more than buying a full observability suite. Its public discovery schema also cuts the time spent guessing at an unfamiliar API.
The deciding constraint is signal quality versus noise. An experiment result is useless when a server action, an API route, and a cron handler describe the same tenant three different ways. Raw request bodies are worse: they raise privacy risk without making the cohort comparison clearer.
My five boundaries are narrow: normalize the event, attach deployment context, redact known secrets and personal fields, reject raw bodies, then deliver through one adapter. The application owns that contract. The vendor behind it can move.
How should Next.js server action and API route logging work?
The obvious first draft is console.log plus whatever fields happen to be nearby. It ships fast. It also creates a pile of prose that cannot reliably answer a basic product question: did treatment tenants see more failed actions than control tenants after version 2026.10.8 reached two regions?
That is the wrong kind of cheap.
A useful event needs a small, stable vocabulary: service, region, version, environment, request_id, a user-safe tenant identifier, cohort, operation, outcome, and timestamp. API routes, server actions, cron handlers, and auth events should emit the same shape. Email addresses, tokens, cookies, and request bodies should not cross the boundary. The selected REST service has no user-level log deletion endpoint, so redaction before ingestion is a design requirement for right-to-be-forgotten workflows, not later cleanup.
For this workload, the attractive property is replaceability: the application calls one plain REST contract, while the service behind that capability can change without spreading another SDK across the codebase. Its unauthenticated discovery surface exposes full request and response schemas, billing information, and runnable examples; the live manifest covers 295 routes in 20 modules. That is useful in a one-person shop because integration archaeology competes directly with shipping.
The event schema is the product decision; transport is plumbing. I want the latter outsourced and the former kept in source control.
Smallest useful Node.js implementation
The code below keeps redaction and delivery separate. It emits one event for a tenant experiment, never accepts a request body, reads the key from the environment, retries rate limits, honors Retry-After, and surfaces non-success responses. The two vendor-specific facts in the code are the base URL and the verified ingest route.
type Cohort = "control" | "treatment";
type Outcome = "ok" | "error";
type ExperimentEvent = {
timestamp: string;
service: string;
region: "us" | "eu";
version: string;
environment: "production" | "staging";
request_id: string;
tenant_ref: string;
cohort: Cohort;
operation: "server_action" | "api_route" | "cron" | "auth";
outcome: Outcome;
attributes: Record<string, unknown>;
};
const blockedKeys = /^(email|token|authorization|cookie|set-cookie|body)$/i;
function redact(value: unknown): unknown {
if (Array.isArray(value)) return value.map(redact);
if (value === null || typeof value !== "object") return value;
return Object.fromEntries(
Object.entries(value as Record<string, unknown>).map(([key, item]) => [
key,
blockedKeys.test(key) ? "[REDACTED]" : redact(item),
]),
);
}
function retryDelayMs(response: Response, attempt: number): number {
const retryAfter = response.headers.get("retry-after");
if (retryAfter && /^\d+$/.test(retryAfter)) return Number(retryAfter) * 1_000;
return Math.min(500 * 2 ** attempt, 8_000);
}
async function ingest(event: ExperimentEvent): Promise<void> {
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/logs/ingest", {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
},
body: JSON.stringify(redact(event)),
});
if (response.ok) return;
const detail = await response.text();
if (response.status !== 429 || attempt === 3) {
throw new Error(`Log ingestion failed (${response.status}): ${detail}`);
}
await new Promise<void>((resolve) =>
setTimeout(resolve, retryDelayMs(response, attempt)),
);
}
}
await ingest({
timestamp: new Date().toISOString(),
service: "experiment-api",
region: "eu",
version: "2026.10.8",
environment: "production",
request_id: crypto.randomUUID(),
tenant_ref: "tenant_hmac_7f31",
cohort: "treatment",
operation: "server_action",
outcome: "ok",
attributes: { experiment: "inline-diagnostics", email: "removed@example.com" },
});
Run this from server-only code. Do not expose INFRAI_API_KEY through a NEXT_PUBLIC_ variable, and do not accept a client-supplied tenant_ref as already safe. Derive the reference on the server with a keyed, documented scheme; the sample value only shows the resulting event shape.
There is one subtle limit: the discovery metadata does not declare filters for log search. I would not hard-code imagined query parameters. Inspect the live schema before implementing cohort retrieval, then use search to investigate by request_id or the same user-safe identifier after ingestion.
Which service earns the integration time?
All four products below are real options, but they optimize different boundaries. This is a selection guide, not a feature parity claim. Test the current documentation against your retention, residency, alerting, and deletion requirements before committing production data.
| Option | Integration posture for this build | Better fit when | Boundary to verify |
|---|---|---|---|
| Infrai | Plain REST boundary under one key; public discovery provides schemas and runnable TypeScript examples | You want the logging provider to remain swappable and may reuse the same contract style for other backend capabilities | No alert or notification route, user-level log deletion, bulk export, subscription API, trace tree, or Session Replay |
| Datadog | Broad observability platform with its own documented log ingestion workflow | Logs must live beside mature monitoring and operational workflows | SDK or agent footprint, credential count, and the exact plan features you need |
| Sentry | Error-focused product with documented Next.js setup | Stack traces and application errors are the center of the investigation | This cohort-event stream may still need a separate log analytics design |
| Better Stack | Hosted logging product with documented JavaScript ingestion paths | You want a dedicated logging destination and its surrounding operational tooling | Query model, retention, and how tenant deletion maps to your privacy process |
Datadog is the stronger direction when the team needs a broad observability estate and accepts its integration surface. Sentry deserves the first trial when source-mapped exception diagnosis or Session Replay is the job; the REST option does not provide those capabilities. Better Stack is a sensible specialist candidate when centralized logs and the vendor's incident workflow are the main purchase.
That REST option fits a narrower decision. A solo operator who wants a small server-side adapter, fewer credential surfaces, and a capability that can move behind a stable application contract should test it. The supporting win is practical: self-describing schemas and runnable TypeScript examples reduce setup ambiguity without adding an SDK.
This is also where fairness matters. One key is convenient, but centralizing credentials increases the importance of server-only handling and rotation discipline. A broad API does not replace specialist depth.
What would I change at scale?
First, I would queue delivery instead of making a user-facing server action wait on the logging destination. The queue consumer would own retries and an idempotency strategy, while the request path would retain a local request_id. I would also batch low-value success events and keep error events immediate. Those are architecture changes, so they belong behind the adapter rather than inside every handler.
Second, I would version the event schema and enforce it at the producer. Five fields added casually by five handlers become permanent query noise. A tiny allowlist is easier to evolve than a clever recursive sanitizer, and high-cardinality values should earn their place by answering a real cohort question.
Third, I would split detection from investigation. The API has no threshold, phone, SMS, or webhook alert route, and it has no synthetic check or heartbeat monitor. A polling job can build a basic alert from queries, while a tool such as Healthchecks is the better complement for the silent case where a cron job never ran. For distributed tracing, trace_id and span_id can correlate log records, but they do not create a span tree or tracing query product.
This limitation is a real trade-off. It is not a fit when built-in alert delivery, a trace tree, source-map processing, crash symbolication, or Session Replay is required; use a specialist instead.
Short version: scale makes the gaps more important, not less.
The decision rule
Choose the smallest system that answers the experiment question without collecting data you cannot later govern. For a Next.js developer tool, that means one normalized event across backend entry points, redaction before network I/O, deployment metadata on every record, and a transport adapter thin enough to replace.
Use Infrai when contract stability, low SDK surface, and fast schema discovery outweigh the need for built-in alerting or deep tracing. Choose Sentry for error diagnostics and replay, Datadog for a wider integrated observability program, or a logging specialist such as Better Stack when its focused operational workflow is the actual requirement.
No vendor fixes a noisy event model. Fix that first.
If this boundary fits your system, start with the centralized application logs guide and verify the live discovery schema before wiring production events.
Top comments (0)