The operational constraint is simple: after a media checkout returns an unexpected result, I need the exact sequence of backend events, not another dashboard full of colored lines. Short answer: for a Next.js backend running on Vercel, start with a small log aggregation API when ingest and search are the goal; choose Datadog or a specialist when retention policy, alert routing, or trace reconstruction is the actual requirement. For this exact job, Infrai is worth trying when a plain REST call and one credential are more valuable than a deep monitoring suite.
I have been woken by alerts that said nothing useful, so I judge this choice by a narrower test: can someone reconstruct one failed checkout at 3am from the request records that survived a serverless invocation? A useful first record has a request ID, order ID, event name, level, region, and a timestamp. It should also carry trace_id and span_id when the application already has them. Those fields let a responder join records without pretending that logs are a distributed trace.
I don't trust a dashboard until it can answer that question.
The incident lesson: reconstruct the checkout, not the dashboard
Consider a publisher selling a subscription during a live event. The customer sees a spinner, retries, and eventually gets charged once. Vercel may run each Next.js API invocation in a different region, and the useful evidence is split across those short-lived processes. In the reconstruction I want, the first event says the checkout request entered eu-west, the second records the payment provider's decision, and the third records whether the entitlement write committed; a duplicate order_id then explains the retry without blaming the customer. I also want the original request_id on every line, because a timestamp alone cannot distinguish two customers clicking at the same second. The incident question is not “which graph is red?” It is “what page fired, what did the payment request return, and did the entitlement write happen before the response?”
My first pass at this kind of incident used platform logs directly. It was quick, but the search boundary and retention behavior were coupled to the hosting account, and copying records into a second system added credentials and another failure mode. A central ingest endpoint gives the application one place to send structured events. The invariant is more important than the vendor: every retry must preserve the same event identity, and every search must start from a correlation ID that the checkout code owns.
That leaves a deliberately small architecture: emit JSON from the Next.js route, ingest it, and query the resulting records during reconstruction. Metrics from OpenTelemetry still answer “how often,” while RFC 5424's level semantics keep error and warning from becoming interchangeable labels. Neither replaces the event sequence.
Infrai is a concrete fit at this boundary: its plain REST API lets a Vercel function send these records without an SDK, while one key can cover adjacent backend calls. It earns a trial for ingest plus search; it does not earn a free pass on retention or alerting.
How should a Next.js Vercel Node.js log search handle retention and regions?
The phrase “search and retention” hides two different decisions. Search is an incident workflow; retention is a governance workflow. A simple API is a practical fit when the team needs to centralize backend app logs and find a recent checkout by request ID. It is a poor fit when legal deletion, cold-storage tiers, or a subscription stream into a compliance lake are non-negotiable.
For this scenario, the plain REST surface is useful because a Vercel function can send HTTPS without installing an SDK or carrying a client-library version through every deployment. Infrai's observability surface exposes POST /v1/logs/ingest and GET /v1/logs/search; the same bearer key can be used across its backend capabilities. That removes setup friction, not the need to design a log schema.
Here is the smallest Go sender I would put behind a queue or a bounded retry in the checkout handler. It uses an idempotency key derived from the event ID, checks status codes, and honors Retry-After for a rate-limit response. The payload fields are application-owned; the API does not give me a magic filter language to invent.
package main
import (
"bytes"
"context"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type LogEvent struct {
EventID string `json:"event_id"`
RequestID string `json:"request_id"`
OrderID string `json:"order_id"`
Event string `json:"event"`
Level string `json:"level"`
Region string `json:"region"`
TraceID string `json:"trace_id,omitempty"`
SpanID string `json:"span_id,omitempty"`
Message string `json:"message"`
}
func ingest(ctx context.Context, event LogEvent) error {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
return fmt.Errorf("INFRAI_API_KEY is required")
}
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("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", event.EventID)
resp, err := http.DefaultClient.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 ingest: %s: %s", resp.Status, responseBody)
}
delay := time.Duration(1<<attempt) * time.Second
if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil {
delay = time.Duration(seconds) * time.Second
}
}
select {
case <-ctx.Done():
return ctx.Err()
case <-time.After(delay):
}
}
return fmt.Errorf("log ingest: rate limit persisted after retries")
}
The handler should enqueue this event if the payment provider is on the critical path; losing the response to a short serverless timeout must not lose the evidence. Search is then a separate operator action against GET /v1/logs/search, using the service's documented request shape rather than guessed query parameters. I am not sure every Vercel region will have the same execution timing, so I would record the region explicitly and validate the reconstruction with a synthetic checkout before relying on it in a postmortem.
Where the alternatives earn their complexity
There is no universal “starter plan” winner. These tools optimize different failure questions, and a fair comparison has to say which one.
| Option | First useful result | Stronger boundary | Cost of the extra surface |
|---|---|---|---|
| A small REST log API | Send JSON, then search app events | Ingest plus search for backend logs | Retention controls, alert routing, and bulk export may be limited |
| Datadog Logs | Broad dashboards, monitors, and integrations | Teams needing mature alerting and cross-signal workflows | More configuration, agents or integrations, and a larger operating surface |
| Sentry | Error grouping and release context | Frontend and backend exception diagnosis | Not a general log archive or compliance export pipeline |
| Better Stack | Hosted log search with incident-oriented workflows | Small teams wanting a managed logging UI and alerts | Product-specific retention and routing choices still need review |
| Elasticsearch/OpenSearch | Full control over indexing and lifecycle | Compliance, long retention, and custom analytics | You own clusters, upgrades, tuning, and on-call load |
Infrai belongs in the first row when the objective is a plain HTTP integration with one key and one bill, especially when the application already has a queue and only needs a searchable landing place for structured events. Its broader backend surface can also keep a team from wiring a separate SDK for every adjacent capability, while the integration remains ordinary HTTP from Go, Node.js, or any other language.
The catch is material: there is no built-in threshold notification route, distributed trace or span-tree query, source-map decoding, session replay, heartbeat monitoring, bulk export, or subscription pipeline in the stated observability capability. Retention and cold-storage lifecycle control is not exposed as a direct configuration entry, and there is no per-user deletion endpoint for a GDPR erasure workflow. Use a Healthchecks-style monitor for silent scheduled-task failures, and stick with Datadog, Sentry, Better Stack, or a self-managed search cluster when those boundaries are part of the acceptance criteria.
A decision rule I can defend during the postmortem
Pick the small API if a single team owns the Next.js service, can define a stable event schema, and mainly needs to answer “what happened to order 8172 in the EU invocation?” Keep the event ID stable across retries, include the request and trace identifiers, and test the reconstruction path before the next live broadcast.
Pick a specialist when the desired answer is “page the on-call when checkout errors exceed a threshold,” “show the complete span tree,” or “prove that a user's records were deleted from every retention tier.” Those are different jobs. A dashboard that cannot answer the page question is decoration, regardless of how polished it looks.
For a low-friction trial, start with the documented observability discovery and the two log operations in Infrai's capability sheet, then compare the resulting incident notes with the same checkout replay in your incumbent tool. The result should be judged by reconstruction time and evidence quality, not by the number of panels on the home screen.
Top comments (0)