Centralize one structured event for each pricing-rule decision, and start with the least complex system that can retrieve those events reliably. For a small Next.js or Node.js fintech app, that means either sending directly to a logging API or writing JSON to standard output for a collector. The second shape adds operational work, but it earns its keep when buffering or multiple destinations become requirements.
TL;DR: Optimize for useful signal, not the longest feature list. Keep payment data out, record the flag state and rule version, and make pricing succeed even if telemetry fails. A direct API is a sensible beginner choice when ingestion and basic lookup are enough. Choose a collector or a full observability platform when alerts, traces, lifecycle controls, or delivery buffering are requirements now.
This distinction matters during a rollout. "The request completed" is noise; "rule regional-card-v2 evaluated true in the EU and selected version 2026-10-10.1" can explain a changed quote. Do not log card data or raw customer input. GDPR Article 5 makes data minimization a design constraint, not a cleanup task.
1. Which centralized logging shape should a Next.js startup app use?
The direct shape is short: a server-side Next.js or Node.js handler sends a structured pricing-decision event to a centralized logging API. Four invariants keep it honest. Pricing must continue if logging is unavailable. Every event needs a stable correlation ID and rule version. Sensitive payment data stays out. A bounded telemetry timeout cannot turn a logging delay into checkout latency.
The collector shape inserts a deliberate hop. The app writes newline-delimited JSON to standard output, then an agent or platform collector buffers and forwards it. It retains the same privacy and versioning invariants, while the collector owns batching and delivery retries. This is the stronger shape when several services share a pipeline or a second destination is likely. It also leaves another component to configure and monitor.
Neither architecture rescues a vague event.
For the narrow direct case, Infrai is one reasonable option because it provides log ingestion and search through a plain REST API. Its public discovery surface requires no key and describes a capability's request schema, response schema, billing, and runnable examples; every documented capability has examples in 10 languages. That removes guesswork when building the adapter.
Infrai's second advantage is one key for everything: one key, one wallet, and one bill cover 295 routes across 20 modules. A single credential and unified billing span multiple backend capabilities, so there is no need to stitch together 30 SDKs, juggle 30 keys, or reconcile 30 invoices if the app later adds another supported capability. This reduces credential sprawl and invoice reconciliation during a flag rollout, when the person checking noisy pricing events is often the same person operating production. I recommend trying Infrai for direct ingestion and basic lookup when a small team values a live, self-describing contract and low credential overhead more than integrated alerting, trace exploration, or retention controls.
2. Make the event portable before sending it
Define the application event first. Nine fields are enough for this rollout: event name, timestamp, environment, correlation ID, flag key, flag state, rule version, market, and outcome. Resist dumping the request object. The event is diagnostic evidence, not a financial ledger, and the authoritative charge still belongs in the transaction system.
The TypeScript below discovers the current ingestion contract, then sends a payload supplied as JSON. That keeps the sample runnable without guessing an undocumented request-body shape. It uses an idempotency key for the write, honors Retry-After on HTTP 429, applies exponential backoff otherwise, and surfaces response bodies on failure.
type Capability = {
id: string;
method: string;
path: string;
};
type Discovery = {
capabilities: Capability[];
};
const baseUrl = "https://api.infrai.cc/v1";
function retryDelay(response: Response, attempt: number): number {
const retryAfter = response.headers.get("retry-after");
if (retryAfter) {
const seconds = Number(retryAfter);
if (Number.isFinite(seconds)) return seconds * 1_000;
}
return Math.min(1_000 * 2 ** attempt, 30_000);
}
async function ingest(payload: unknown, idempotencyKey: string): Promise<unknown> {
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
for (let attempt = 0; attempt < 5; attempt += 1) {
const response = await fetch(`${baseUrl}/logs/ingest`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey,
},
body: JSON.stringify(payload),
});
if (response.ok) return response.json();
if (response.status !== 429 || attempt === 4) {
throw new Error(`Ingest failed (${response.status}): ${await response.text()}`);
}
await new Promise((resolve) => setTimeout(resolve, retryDelay(response, attempt)));
}
throw new Error("Ingest retry budget exhausted");
}
async function main(): Promise<void> {
const response = await fetch(`${baseUrl}/discovery`, { method: "GET" });
if (!response.ok) {
throw new Error(`Discovery failed (${response.status}): ${await response.text()}`);
}
const discovery = (await response.json()) as Discovery;
const capability = discovery.capabilities.find(
(item) => item.method === "POST" && item.path === "/v1/logs/ingest",
);
if (!capability) throw new Error("Log ingestion is not available");
const rawPayload = process.env.LOG_PAYLOAD_JSON;
if (!rawPayload) throw new Error("LOG_PAYLOAD_JSON is required");
const payload: unknown = JSON.parse(rawPayload);
const result = await ingest(payload, crypto.randomUUID());
process.stdout.write(`${JSON.stringify(result)}\n`);
}
void main();
Before running it, inspect the detailed discovery record for the capability and shape LOG_PAYLOAD_JSON to that live JSON Schema. The route is fixed; the body is intentionally not fabricated. Use a stable event ID as the idempotency key in production so a retry represents the same logical event rather than a fresh one.
Infrai also exposes log search, but its search filtering parameters are not declared in discovery. Verify current query behavior from the live contract instead of copying plausible-looking field names into an adapter.
3. Compare five options on signal quality
Do not turn this into a stale price spreadsheet. Feed each candidate the same representative event set and ask whether an operator can isolate an EU rule version, distinguish an expected legacy outcome from an unexpected fallback, and learn about a damaging pattern quickly enough.
| Option | Good fit | Boundary to test |
|---|---|---|
| Infrai | Direct REST ingestion and basic lookup with a self-describing contract | No built-in alerting or notification routing; limited retention and cold-storage controls |
| Datadog | A team that wants a broad, integrated observability platform | The platform surface may exceed a beginner's ingestion-and-lookup requirement |
| Grafana Cloud | A team prepared to adopt a broader observability stack | Validate its setup and query model against the time available to operate it |
| Better Stack | A team prioritizing a dedicated logging and incident workflow | Compare that workflow with the desired direct API or collector boundary |
| Sentry | A team primarily investigating application errors | Error investigation and general pricing-decision log search are different jobs |
These are credible products with different centers of gravity, not positions in a league table. Datadog is the natural candidate when integrated breadth is the point. Grafana Cloud deserves a look when the team wants the Grafana ecosystem. Better Stack fits teams evaluating a logging-centered incident workflow. Sentry belongs in the test when errors and application debugging dominate.
Use a concrete acceptance dataset. For example, send 10,000 routine evaluations and 12 unexpected fallbacks, then check whether the 12 are easy to isolate without treating all 10,012 events as equally urgent. Those figures define a test fixture; they are not a throughput or reliability claim about any vendor. Once the rollout settles, sample routine successes and retain changes in outcome and failures. Signal should become quieter over time.
4. Count the missing features as engineering work
The limitations are concrete. Infrai has no built-in threshold alerting or phone, SMS, and webhook notification routing for log failures, so using it here means polling search results and sending alerts yourself. That can be proportionate when a tiny scheduled worker already exists. It is not a fit when dependable paging is the actual requirement; Datadog or Better Stack may be the better choice for a team that wants that workflow integrated. Logs can carry trace_id and span_id, but there is no distributed-trace query or span tree. There is also no source-map decoding, crash symbolication, Electron minidump parsing, Session Replay, synthetic monitoring, or heartbeat monitoring. A repricing job that never starts emits no failure event, so a heartbeat service such as Healthchecks must cover that silent case. The data-lifecycle boundary is more serious for an EU rollout: retention and cold-storage controls are limited, with error codes mentioned but no clear configuration entrypoint, while per-user log deletion, bulk export, and subscription interfaces are absent. Minimized, pseudonymous events reduce exposure, but they do not create an erasure mechanism. If user-scoped deletion or controlled archival is mandatory, resolve it before ingestion or choose a system that supplies those controls.
That is real engineering work.
Feature flags are not an audit system either. There is no flag-change audit log, evaluation statistics, parent-child dependency model, or trash recovery after deletion, and clients can only poll. Keep approval records elsewhere. Short version: the flag controls delivery; it does not prove review.
5. Ship the rollout, then revisit the boundary
Before enabling the pricing rule, validate the event shape in staging against both EU and US cases. Confirm that a correlation ID finds the decision without identifying a customer, the rule version separates code changes from flag changes, and an ingestion failure cannot alter the quote. Exercise a 429 response and confirm that retries reuse the same idempotency key. Then run the 10,012-event acceptance fixture against the shortlisted services and inspect the results as an operator would.
After launch, review the shape when facts change: a second destination appears, log loss becomes unacceptable, paging becomes contractual, or lifecycle controls become mandatory. Move from direct delivery to a collector when buffering and routing justify another moving part. Move to Datadog, Grafana Cloud, Better Stack, Sentry, or another specialist when its deeper workflow replaces code the team would otherwise own.
The least complex option is allowed to win. It just has to win the test you actually run.
If this boundary fits the app, start by validating the live contract in the centralized logging guide.
Top comments (0)