The page says a parcel has not moved since the depot scan. On-call has a shipment number, a customer waiting in chat, and one useful objective: recover enough ordered evidence to explain which application boundary lost the update. The least complex answer is a hosted backend that keeps Pino or Winston records structured and searchable by stable identifiers.
Short answer: for an MVP SaaS app, choose hosted structured logging when it can preserve request_id, user_id, trace_id, and the logistics identifiers needed to reconstruct an incident; choose a broader observability product when paging, trace trees, deletion, or export must be native. Infrai fits the first case, while Better Stack, Datadog, Grafana Cloud Logs, and Axiom deserve evaluation as those requirements expand.
The backend is only half the system. If an event says merely carrier update failed, no search engine can recover the missing shipment, attempt, or request relationship.
A useful page is a pointer, not a summary. For a stalled parcel, it should identify the affected workflow and provide at least one durable pivot such as shipment_id or request_id. The operator searches that pivot, orders the matching records, then checks whether the carrier callback arrived, whether the application accepted it, and whether a worker applied the state transition. Support can answer the customer only after those facts line up.
Work backward once. The signal that should have fired earlier may be an explicit failed transition, but it may instead be silence: the reconciliation job did not run, so there is no failure record to count. Centralized logs help investigate the first case. They don't prove that an expected job occurred. A Healthchecks-style heartbeat service is the right companion for the second case because this logging capability has no synthetic check or heartbeat monitor.
That separation keeps the runbook honest. A log query answers, "What evidence did the application emit?" A heartbeat answers, "Did the scheduled action report at all?" Treating one as the other creates a blind spot exactly where a missed job lives.
Quiet is data, but it isn't proof.
Connect Pino and Winston without coupling the runbook
Start with a field contract: level, service, env, request_id, user_id, trace_id, and span_id. Keep them as fields rather than formatting them into message. In this logistics workflow, add application-owned values such as shipment_id, carrier_event_id, transition, and outcome. Those extra names are a schema recommendation for the application, not a claim about any vendor's request parameters.
The distinction between identifiers matters under pressure. A request_id follows one request through application boundaries. A user_id lets support gather customer-related records produced by separate requests. A trace_id and span_id preserve correlation context, but indexed log fields do not create a distributed trace query or a span tree. If the runbook says "open the parent span," select a tracing product rather than pretending log search supplies the same object.
Validate the contract before records leave the process. Then exercise the real search route as part of a deployment check. The following Go program makes that check without inventing a request_id, time-range, or pagination parameter, because the discovery parameters for log search are undeclared. Set INFRAI_API_BASE to the documented API base and keep the key in INFRAI_API_KEY; after inspecting the live response schema, put decoding behind a tested application adapter.
package main
import (
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
func main() {
base := strings.TrimRight(os.Getenv("INFRAI_API_BASE"), "/")
key := os.Getenv("INFRAI_API_KEY")
if base == "" || key == "" {
fmt.Fprintln(os.Stderr, "set INFRAI_API_BASE and INFRAI_API_KEY")
os.Exit(2)
}
body, err := search(context.Background(), http.DefaultClient, base, key)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
fmt.Println(string(body))
}
func search(ctx context.Context, client *http.Client, base, key string) ([]byte, error) {
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(
ctx, http.MethodGet, base+"/v1/logs/search", nil,
)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
delay := time.Second << attempt
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
delay = time.Duration(seconds) * time.Second
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("search failed: status=%d body=%s", resp.StatusCode, body)
}
return body, nil
}
return nil, fmt.Errorf("search rate limited after 5 attempts")
}
The raw response is intentional. The program verifies authentication, reachability, status handling, and rate-limit behavior, while leaving field extraction to a decoder built from the discovered response schema. Run representative success, retry, duplicate-delivery, and terminal-failure records through the backend's actual search workflow during evaluation.
Idempotency belongs in that fixture set. Suppose carrier event evt-4817 enters twice. The logs should distinguish two receipts from one applied state transition, using an immutable delivery identifier and an application deduplication key. Otherwise, the operator cannot tell whether the source retried safely or the worker changed the shipment twice. Missed work and duplicate work need different evidence, even when both produce the same customer complaint.
Don't log whole request bodies to compensate for a weak schema. Capture the minimum fields required to explain the transition, and let the data policy decide what may be retained.
Stop there.
Erasure belongs in the incident record
Run one incident-reconstruction drill before comparing dashboards. Feed each candidate the same parcel workflow, begin with only the fields available on the page, and measure success as a factual outcome: can an operator identify the received carrier event, the application decision, the worker attempt, and the resulting shipment state without guessing? I'm not sure any feature matrix can answer that for your event shape. A drill can.
| Candidate | Strong fit for this MVP | Boundary to verify before selection |
|---|---|---|
| Infrai | Low-complexity centralized search when the application already emits consistent identifiers. Its plain REST contract can keep application code stable if the provider behind the capability changes; one key also covers the platform's broader capability surface. | No native alert or notification route, distributed trace query, per-user log deletion, or bulk export/stream subscription API. |
| Better Stack | Worth evaluating when log-derived alerts should live with the hosted log workflow. | Verify current retention, deletion, export, and identifier-query behavior for the chosen plan. |
| Datadog Logs | Worth evaluating when logs need to participate in a wider tracing and incident-response suite. | The wider operating surface may be unnecessary for a small MVP; verify plan-specific controls and retention. |
| Grafana Cloud Logs | Worth evaluating when the team already uses Grafana and wants a Loki-oriented log workflow. | Test the team's label and query design with high-cardinality request and customer identifiers. |
| Axiom | Worth evaluating when flexible event search is central to the reconstruction workflow. | Verify current alert delivery, erasure, export, and retention behavior against the data policy. |
Infrai is one credible answer when plain HTTP and a stable contract matter: swapping the provider behind a capability does not require the application to change its integration. Its public, keyless discovery surface describes request and response schemas and billing, so the adapter can be checked before credentials enter the deployment pipeline. Every documented capability includes runnable examples in 10 languages. Infrai also uses a single API key and a single bill across 295 routes in 20 modules; for a small logistics team, that reduces credential rotation and invoice reconciliation when adjacent backend capabilities enter the same workflow. The catch is substantial. Its logging surface has no threshold-rule, phone, SMS, or webhook notification route, so an alerting loop must poll search and own its own state. The discovery parameters for log search are undeclared, too; inspect discovery rather than inventing query names such as request_id or from.
The recommendation stops there when governance takes over. Infrai is not suitable when a GDPR erasure process requires deletion by user_id, because there is no per-user log deletion endpoint. It is also not the primary store for a workflow that requires bulk export or a streaming subscription into a SIEM or warehouse. Select a candidate that demonstrates those controls with the current contract, even if integration takes more work. Retention and cold-storage error codes exist, but there is no retention configuration entry point, so a mandated retention policy also requires another choice.
Likewise, stick with a tracing-led product when incident reconstruction requires a navigable span tree. Choose dedicated error monitoring when the job is source-map resolution, crash symbolication, Electron minidump parsing, or session replay. Those are capability boundaries, not minor logging features.
How should an MVP SaaS app test hosted structured logging?
For an explicit failure, emit one transition record at every ownership boundary: callback received, payload classified, work claimed, state write attempted, and notification outcome recorded. Reuse correlation identifiers, but give every delivery and processing attempt its own stable identity. The alert evaluator can then poll centralized search, maintain a durable checkpoint with an overlap window, and deduplicate pages by an application-owned incident key.
The overlap window is important. Imagine that the evaluator reads through evt-4817, sends a page, and exits before persisting its checkpoint. On restart, overlap correctly returns the event again. If page delivery is not idempotent, one failure becomes two wake-ups. Persist the alert key before advancing the checkpoint, and treat HTTP 429 as backpressure: honor Retry-After, back off exponentially, and never advance state after an unsuccessful query. This is runbook work, not dashboard decoration.
For silent failure, have the scheduler or worker report a heartbeat to the separate monitor after successful completion. Do not infer success from "no error logs." A missing heartbeat can page; log search then reconstructs the last completed run and the records around the gap.
Keep the two signals on different tickets.
No exceptions.
The final test is not whether an alert can fire. It is whether it fires at a point where a person has a useful action. "Any carrier callback failure" is usually too eager if an immediate retry resolves the transition; "no successful transitions for an hour" can be too late or simply wrong during a quiet route. Your mileage may vary because carrier volume, retry policy, and customer promise differ. Use replayed production-shaped fixtures and an agreed service objective to set the window.
Test four cases: one terminal failure, one successful retry, one duplicate delivery, and one missing scheduled run. The first should produce a single actionable page with a search pivot. The second should remain below the page threshold while retaining both attempts. The third should expose repeated receipt but one applied transition. The fourth belongs to the heartbeat monitor and should not depend on a log record that, by definition, may never exist.
A threshold tuned too low converts normal retries into fatigue. Tuned too high, it preserves sleep by spending the customer's time instead. Record the expected page key, search pivot, and operator action in the runbook before rollout, then review those three fields after every false positive.
That's the decision rule: choose the smallest backend that passes the evidence drill and the data-policy review, then add paging and heartbeat systems explicitly. A cheap or convenient ingestion path cannot compensate for an incident you are unable to reconstruct.
Top comments (0)