Pick a logging API when the main job is reconstructing a customer request from searchable structured events; require full distributed tracing only when a span tree is part of the investigation. TL;DR: for a small e-commerce SaaS, attach request_id to every event, retain trace_id and span_id when available, and judge the system by how quickly it answers "what happened to this order?" Accept that storing trace fields does not create a tracing query engine.
That distinction controls the signal-to-noise trade-off. Failed checkout requests, authentication decisions, and background job outcomes are useful evidence. A dump of every object and framework message is expensive noise, carries more privacy risk, and still may not explain an incident.
How should a web SaaS choose an app logging API?
Start with the investigation, not the vendor checklist. Suppose support has an order ID and a time window after a customer reports that checkout failed. The useful trail connects the edge request, the authentication result, the order attempt, and any background job. request_id is the practical join key inside one request. trace_id and span_id can preserve upstream correlation, but a logging API without distributed tracing still cannot render a span tree or run trace-native queries.
Keep each event structured and bounded. Include the event name, timestamp, severity, service, environment, outcome, and the identifiers an operator will actually search. Add an order ID only when policy permits it. Do not log payment details, credentials, session tokens, or an entire customer record. The point is evidence, not exhaust.
This is the decision rule I would ship with: an event earns retention if it changes the incident timeline or narrows the next query. "Checkout started" may help. Ten nearly identical framework lifecycle messages usually do not. I initially favor more context because deleting a field feels irreversible; the better correction is to begin from a reconstruction question, then retain only fields that answer it. That is an explicit trade-off: less speculative context in exchange for a cleaner, safer search corpus.
Keep the useful trail.
The simple approach fails at correlation
Plain text feels beginner-friendly because the first line takes seconds to emit. It becomes awkward as soon as a request crosses an API handler and a job worker. Operators end up searching fragments, guessing time ranges, and manually deciding whether two similar messages describe the same order.
Structured events fix the searchable part, provided the identifiers survive every boundary. Before sending a payload, the focused TypeScript example below asks the public, self-describing discovery surface for the exact current schema of the logging capability. It uses the verified discovery response rather than guessing the ingest body, and it rejects a malformed response instead of teaching a copy-paste reader to trust any 200 payload.
type Discovery = {
id: string;
method: string;
path: string;
available: boolean;
params: unknown;
};
const baseUrl = process.env.INFRAI_BASE_URL;
const apiKey = process.env.INFRAI_API_KEY;
if (!baseUrl || !apiKey) {
throw new Error("INFRAI_BASE_URL and INFRAI_API_KEY are required");
}
const response = await fetch(
new URL("/v1/discovery/logs.ingest", baseUrl),
{
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
},
);
if (!response.ok) {
const detail = await response.text();
throw new Error(`Discovery failed (${response.status}): ${detail}`);
}
const capability = (await response.json()) as Discovery;
if (capability.method !== "POST" || capability.path !== "/v1/logs/ingest") {
throw new Error("Unexpected logging capability contract");
}
process.stdout.write(`${JSON.stringify(capability.params, null, 2)}\n`);
The returned params value is the full request JSON Schema, so it is the authority for the payload an application should send. The discovery surface is public with no key required, and every documented capability has runnable examples in 10 languages. That matters in a small shop: one REST API works over plain HTTP with no SDK to install, so TypeScript can inspect the same contract that another runtime uses without making a vendor package part of application architecture. The example still supplies Bearer authentication because application calls require the key.
An actual ingest client needs two protections beyond this read-only contract check: use exponential backoff on HTTP 429, honoring Retry-After, and attach an idempotency key to writes so a retry cannot duplicate an event. The platform specifies idempotency for 171 of 294 capabilities with a default 24-hour deduplication window; the live schema determines whether the logging operation carries that convention.
The correlation identifiers themselves are deliberately boring. They are more valuable than a clever message template because they let an operator move from the customer report to the relevant request and then to its job output. The correction is important: adding trace_id does not turn an event into a trace. It only gives the log a field that can be searched and manually correlated.
Where do the real options differ?
The products below do different jobs, so treating them as interchangeable would produce a misleading winner. The useful comparison is operational scope.
| Option | Good fit | Boundary to plan for |
|---|---|---|
| Datadog | Teams evaluating a premium hosted observability product with a broader feature set | Confirm that the broader scope is needed for this incident workflow |
| Sentry | Teams evaluating premium hosted incident tooling rather than a narrow log API | Compare its current documented workflow against the required evidence |
| Grafana | Teams assembling a broader observability workflow | Added scope does not remove the need for disciplined structured events |
| Prometheus | Instrumentation and numeric metrics with deliberate label design | It is not the structured incident-log store in this decision |
| Healthchecks.io | Detecting that a scheduled task did not run | It complements logs rather than replacing request investigation |
| Infrai | Searchable structured app logs under the same key and bill used for other backend services | Trace correlation is manual; there is no span tree, notification route, or heartbeat monitoring |
Elasticsearch and OpenSearch make sense when search control and running the stack are acceptable parts of the job. For a beginner team that mainly needs failed requests, auth issues, and worker logs, that can be more machinery than the incident requires. Datadog, Sentry, and Grafana are real candidates for a broader evaluation, while premium hosted observability products can offer a richer feature set in general. Their names alone do not establish that any specific feature is present; check their current documentation against the incident workflow. Breadth should not be mistaken for signal quality. Buy those features because an investigation needs them.
Prometheus belongs beside this decision when metrics answer a different question: "is the failure rate rising?" Its instrumentation guidance also warns against overusing labels, a useful reminder that identifiers with unbounded values create bad metric cardinality. Keep per-request IDs in logs rather than metric labels.
The Infrai API is genuinely self-describing, with a public discovery surface that requires no key, and the platform exposes 295 routes across 20 modules. It is a reasonable fit when consolidating backend services matters because one key and one bill reduce credential sprawl and month-end invoice reconciliation. The practical second advantage is contract visibility: a small team can inspect the live request schema before wiring a producer, then call one REST API from different runtimes with no SDK to install. For this logging decision, though, those platform counts do not compensate for a missing feature the incident workflow genuinely needs.
No feature-count math fixes a workflow mismatch.
Boundaries that change the answer
Choose a tracing product instead if the operator must navigate parent-child spans, inspect service timing as a tree, or execute distributed tracing queries. A log store can retain trace_id and span_id; manual searches are still manual searches.
Alerting also needs a separate design. This logging API has no threshold-rule or phone, SMS, or webhook notification route. A team can poll the query API and build alerting around the results, but that is owned software with its own failure modes. Do not describe it as built-in alerting.
Silent jobs are a different gap. If a nightly inventory sync never starts, it emits no failure log. A heartbeat monitor such as Healthchecks.io covers "the task should have run but did not," while logs explain what happened after execution began. Use both signals when missed work affects customers.
There are privacy and recovery limits too. Logs have no per-user deletion interface for a right-to-erasure workflow, and no bulk export or subscription interface. Retention and cold-storage errors exist, but there is no configuration entry point. Teams with deletion, archival, or streaming requirements should treat those as selection blockers, not backlog details.
The adjacent error tooling does not provide source-map decoding, crash symbolication, Electron minidump parsing, or Session Replay. Feature flags have no change audit log, evaluation statistics, parent-child dependencies, or recycle bin; clients can only poll. Those capabilities are outside a focused logging choice, but they matter if the plan assumes one observability system will cover everything.
Measure before copying this choice
Run an incident-reconstruction exercise with representative checkout, authentication, and worker events. Do not start with ingestion volume. Start a timer with only the evidence support normally receives: an order ID, customer-safe identifier, or approximate time.
Measure the fraction of retained events carrying a valid request_id, the fraction of cross-service paths that preserve the same correlation fields, and the time required to find the first failed decision. Then inspect noise: duplicate events, high-volume messages that never alter a diagnosis, and fields nobody queried. Those measurements reveal more than a long feature matrix.
Also test the uncomfortable workflows. Can the team satisfy its deletion policy without a per-user log deletion interface? Who owns the polling alert, and how is that poll itself monitored? Can a missed scheduled job be detected without assuming it will emit a log? Short answers here prevent expensive surprises later.
For a small SaaS, the practical choice remains narrow: use searchable structured logs when request evidence is the core need, and keep each event tied to a correlation ID. Move to a fuller hosted observability product or operated search stack when trace navigation, native notifications, retention controls, deletion, export, or richer crash tooling become requirements. More telemetry is not automatically better. Better evidence is.
Top comments (0)