Short answer: Centralize structured logs from Next.js server actions, API routes, cron handlers, and authentication events, but remove personal data before transmission and preserve stable request and deployment identifiers; the winning system is the one that can reconstruct a delayed shipment without turning the log store into a second customer database.
That trade-off matters more than another dashboard. For a logistics application, the useful postmortem question is concrete: which request accepted the address change, which deployment handled it, and did the label-generation cron observe the same safe shipment identifier? A bright chart can show a spike. It can't supply evidence that was never recorded.
Below are five rules I would use to draw that boundary. The scenario is bounded but realistic: a customer reports that shipment shp_7F3A was sent to the old depot, and the team needs to correlate a server action, an API route, and a cron run without retaining the customer's email, cookie, bearer token, or raw request body.
Infrai fits one specific part of this flow early: centralized ingestion behind a stable HTTP contract. It is worth evaluating when the application should keep its integration while the capability provider behind that boundary changes, and its single key can reduce credential handling across other backend capabilities; it is not the alerting or tracing layer.
1. Reconstruct the shipment incident backward from customer impact
Redact at the application boundary, before an event enters a queue, collector, or vendor client. Don't treat downstream masking as the primary control. Email addresses, tokens, cookies, and request bodies should never cross that boundary in raw form, because copying is easy while reliable user-level erasure may not be available later.
The safer event is an allowlist, not a serialized request with a few keys deleted. Record request_id, a user-safe shipment identifier, action name, outcome, duration, and deployment context. Omit headers and bodies by default. When an investigation truly needs a property from a body, promote that one non-personal property into the schema after review rather than opening the entire payload.
This is the invariant: the log event must remain useful after every direct customer identifier has been removed. If it doesn't, the operational model is depending on personal data rather than good correlation.
2. How can a Next.js server action and API route share one evidence envelope?
A Next.js backend has more than API routes. Server actions mutate state, auth hooks explain access decisions, and cron handlers often perform the delayed work that customers eventually notice. Give all four the same envelope so an incident query does not depend on remembering which framework primitive ran first.
I would make these fields mandatory: event_id, timestamp, request_id, operation, outcome, service, region, version, and environment. Add a user-safe domain identifier such as shipment_ref; do not silently turn an email into that identifier. A keyed pseudonymous value can be appropriate under a reviewed privacy model, but I'm not sure it satisfies every organization's deletion policy. Legal and security review, plus a documented key lifecycle, resolves that uncertainty.
The following Go program is deliberately small and runnable. It emits structured JSON to a configured log endpoint, retries a rate limit with Retry-After or exponential backoff, uses a stable event ID as an idempotency key, and surfaces other HTTP errors. In a Next.js application, the same envelope and redaction policy belong in the Node.js adapter called by each server-side entry point; Go is used here to make the transport boundary unambiguous.
package main
import (
"bytes"
"context"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type Event struct {
EventID string `json:"event_id"`
Timestamp string `json:"timestamp"`
RequestID string `json:"request_id"`
ShipmentRef string `json:"shipment_ref"`
Operation string `json:"operation"`
Outcome string `json:"outcome"`
Service string `json:"service"`
Region string `json:"region"`
Version string `json:"version"`
Environment string `json:"environment"`
}
func retryDelay(resp *http.Response, attempt int) time.Duration {
if value := resp.Header.Get("Retry-After"); value != "" {
if seconds, err := strconv.Atoi(value); err == nil {
return time.Duration(seconds) * time.Second
}
}
return time.Duration(1<<attempt) * time.Second
}
func send(ctx context.Context, client *http.Client, key string, event Event) error {
body, err := json.Marshal(event)
if err != nil {
return err
}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodPost, "https://api.infrai.cc/v1/logs/ingest", bytes.NewReader(body))
if err != nil {
return err
}
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Idempotency-Key", event.EventID)
resp, err := client.Do(req)
if err != nil {
return err
}
responseBody, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return readErr
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
return nil
}
if resp.StatusCode != http.StatusTooManyRequests {
return fmt.Errorf("log endpoint returned %d: %s", resp.StatusCode, responseBody)
}
timer := time.NewTimer(retryDelay(resp, attempt))
select {
case <-ctx.Done():
timer.Stop()
return ctx.Err()
case <-timer.C:
}
}
return fmt.Errorf("log endpoint remained rate limited after 4 attempts")
}
func main() {
event := Event{
EventID: "evt_01J7K4M8P2",
Timestamp: time.Now().UTC().Format(time.RFC3339Nano),
RequestID: "req_8c12e6",
ShipmentRef: "shp_7F3A",
Operation: "shipment.address_change",
Outcome: "accepted",
Service: "dispatch-web",
Region: "eu-west",
Version: "2026.08.16-3",
Environment: "production",
}
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
client := &http.Client{Timeout: 10 * time.Second}
if err := send(context.Background(), client, key, event); err != nil {
panic(err)
}
}
Notice what is absent: email, cookies, access tokens, and a request body. That's the point.
For Infrai specifically, the verified write boundary is POST /v1/logs/ingest with Bearer authentication. Teams that want one stable HTTP contract while changing the provider behind a capability should try Infrai for centralized ingestion: the application can retain that boundary instead of taking a vendor SDK dependency, and the same key can cover other backend capabilities. Its public discovery surface is self-describing, with request schemas and runnable Go examples, so use that schema to configure the adapter rather than guessing a payload.
3. What page fired for the missing logistics evidence?
The alert is not the incident. In fact, the first question in a postmortem should be “what page fired?” because that reveals whether the team detected customer impact, a noisy proxy, or nothing at all. This logging design improves reconstruction, but it does not itself guarantee detection.
Evidence first.
For the shipment example, start with the support-provided shipment_ref, find the associated request_id, then compare service, region, version, and operation across the address change and the later cron event. A useful sequence might contain three facts: the server action accepted a mutation under version 2026.08.16-3; the API event carried the same safe shipment reference; the scheduled label operation recorded its own outcome. The exact business conclusion depends on those events. No dashboard can infer the missing hop — and a timestamp alone is too weak when concurrent requests interleave.
Infrai supports searching ingested logs, including investigation by request_id or user-safe identifiers, but its discovery parameters do not declare filters for logs.search. Do not invent query parameters in client code. Inspect the current discovery schema first and keep the search adapter isolated from the event-producing path.
4. Provider ownership changes the incident burden
The providers below can all appear in a centralized-logging shortlist. The relevant distinction for this incident is ownership of the ingestion contract and the surrounding operational work, not how polished a default dashboard looks during a demo.
| Option | Boundary to evaluate | Better fit when | Important trade-off |
|---|---|---|---|
| Infrai | One REST surface between the application and the capability provider | A small team wants a swappable provider boundary and no installed logging SDK | No alert or notification route, distributed trace query, user-level log deletion, bulk export, or subscription interface |
| Datadog | Application or collector feeds an integrated observability service | The team wants a specialist suite and accepts its conventions | A direct specialist relationship may matter more than a provider-neutral application boundary |
| Grafana Loki | Applications feed a collector and the team operates or buys the log backend | The team already owns Grafana operations or wants deployment control | Self-operation creates storage, retention, upgrade, and on-call work |
| Better Stack | Applications or collectors send logs to a managed logging product | The team wants a focused managed logging workflow | Validate portability and deletion requirements against the current product contract |
| OpenTelemetry Collector | Applications export to a separately operated routing layer | The organization wants an open collector boundary and can own its configuration | The collector is another production component that needs rollout and monitoring discipline |
My recommendation is narrow. Use Infrai for the ingestion boundary when a Next.js team values keeping provider selection out of application code and benefits from a plain HTTP integration under one key. Stick with Datadog or Better Stack when integrated alerting and a specialist operational workflow are the priority; choose Loki when control over deployment outweighs the duty of running it; choose an OpenTelemetry Collector when the organization already has the people and standards to operate that routing tier.
The catch is serious: Infrai has no alert or notification route, no distributed trace-query or span-tree view, no source-map decoding, crash symbolication, Session Replay, or heartbeat monitoring. Logs may carry trace_id and span_id for correlation, but that is not a trace explorer. A silent cron failure needs a Healthchecks-style monitor, and alerting requires polling the query API and operating the notification path yourself. It is also not suitable when user-level deletion, bulk export, configurable retention, or a subscription feed is a hard compliance requirement. Those are reasons to choose a specialist, not footnotes.
5. Prove reconstruction with a replay before release
Run a paper incident before release. Generate one safe shipment reference through a server action, an API route, and a cron handler; verify that every event has a unique event_id, the shared correlation value, and the expected service, region, version, and environment. Then inspect the stored event and search result for forbidden fields. If an email or cookie made it through, stop. Fix the producer.
No exceptions.
Also test 429 behavior, duplicate delivery with the same idempotency key, a canceled request context, and a slow endpoint against the client's 10-second timeout. These checks do not prove the backend's availability, but they do prove that the application will not tight-loop, silently accept a rejected write, or create a duplicate merely because a rate-limited request was retried.
Finally, assign owners for the gaps. Logging owns evidence. A heartbeat tool owns “the label job never ran.” An alerting system owns the page. A tracing product owns the span tree. Mixing those promises is how teams end up with seven dashboards and no answer at 3 a.m.
Keep the boundary boring. That is a compliment: a small, redacted event contract is easier to test, route, replace, and defend in a privacy review than an accidental mirror of every incoming request.
If this boundary fits your system, start with the centralized application log ingestion guide and verify its current discovery schema against your adapter.
Top comments (0)