Short answer: choose a structured logging platform that can reconstruct one notification attempt from enqueue through provider response; for a budget Next.js SaaS, a hosted logs API is a credible default, while Sentry Logs or Axiom may be the better choice when richer debugging workflows matter more than a narrow, portable event contract.
This architecture decision is about evidence, not log volume. An e-commerce notification service can report that a delivery failed and still leave the operator unable to tell whether the checkout handler, an auth check, a background worker, or the downstream handoff owned the failure. The deciding constraint is incident reconstruction: every stage must emit compatible JSON and preserve stable correlation identifiers.
Don't treat this as a frontend error-tool purchase. It isn't.
How should Next.js SaaS teams test structured logging with hosted logs?
The invariant is simple to state and surprisingly easy to violate: one logical delivery attempt needs one durable identity across server actions, API routes, auth failures, and background jobs. Keep trace_id and span_id in the records so related work can be correlated, but don't mistake those fields for a tracing system. A hosted logs API in this comparison has no distributed-tracing query layer or span tree; correlation remains a log-search exercise.
For a notification attempt, the useful event contract records the business identity, stage, outcome, and a bounded reason code. It should never record the message body, address, authorization material, or an unbounded provider response. Personal data is the sharper boundary here because the hosted capability has no per-user log-deletion endpoint, and deletion or remediation controls are limited. GDPR Article 17 makes erasure a design concern rather than cleanup work to postpone. I'm not sure any retention policy alone resolves that mismatch; a documented data map and a verified deletion test would settle it.
The failure boundaries are equally concrete. Logs can show that a worker started and what it reported, but they cannot prove that a scheduled task ran when the task emitted nothing. There is no synthetic check or heartbeat monitor, so a Healthchecks-style tool must cover silent non-execution. There are also no threshold rules or phone, SMS, or webhook notification routes. A team can poll the query API and build an alert, although that adds an alerting component whose own failure has to be monitored.
This is the uncomfortable part.
Drill the evidence gaps before ranking products
Run one drill with a failed delivery and ask an engineer who didn't build the integration to identify the last successful stage, the owning component, and the bounded reason. Then run the more revealing drill: suppress the worker entirely. The logs should reconstruct the first incident, while the external heartbeat should detect the second. If either case requires searching by personal data, redesign the event contract.
Consider a checkout that accepts order ord_8842, enqueues notification attempt ntf_031, and then hands the work to an email worker. The reconstruction test should let an operator start with the attempt identifier, connect the server action to the queued work through trace_id, distinguish the worker's span_id, and find a bounded provider_rejected outcome without opening a payload that contains the shopper's address. If the enqueue record exists but no worker record follows, the evidence only establishes the last observed stage; it does not establish why execution stopped, nor does it prove that a scheduler ever invoked the worker. That gap belongs to the heartbeat monitor. If the worker record exists and reports the bounded failure, the log search can answer the ownership question. This deliberately modest claim is more useful during an incident than a dashboard that merges silence, rejection, and delayed execution into one red status.
There is a less glamorous data-governance drill too: locate every field that could identify a shopper, then demonstrate how the team would respond to an erasure request. Because the hosted logging capability has no per-user deletion API, the safest record is one that never receives the personal field. No dashboard compensates for a payload that shouldn't have been ingested.
Rank the candidates against fixed invariants
The options should be judged against the same failure narrative, not a feature-count page. Sentry Logs, Axiom, Logtail, and a hosted logs API are all real candidates named in this decision, but the verified evidence here only supports a product-specific distinction for the first two: Sentry or Axiom may be stronger when richer debugging workflows are required. It doesn't support pretending that every product has been benchmarked or that their retention, query speed, and current prices are interchangeable. Your mileage may vary with event volume and the debugging workflow your team already uses.
| Option | Defensible fit for this decision | Boundary or validation needed |
|---|---|---|
| Sentry Logs | Prefer when richer debugging workflows outweigh a narrow logging-only decision | Validate the structured event contract against the delivery stages |
| Axiom | Prefer when richer debugging workflows are part of the purchase | Validate the same reconstruction query with representative events |
| Logtail | Keep in the shortlist from the original platform comparison | Test the full delivery narrative before drawing a product-specific conclusion |
| Hosted logs API | Fits centralized JSON from server actions, API routes, auth failures, and jobs | No span tree, replay, source-map deobfuscation, built-in alert routing, heartbeat monitoring, per-user deletion, bulk export, or subscription interface |
Infrai uses one REST API. It works over plain HTTP without an SDK, from any language or runtime, so a Next.js server action and a Python background worker can share the same integration boundary.
For Infrai, one key and one bill cover a broad, consistent contract: 295 routes across 20 modules sit behind that credential, and adding another backend capability can mean another endpoint rather than another client library and credential set. Its public discovery surface is self-describing and every documented capability includes runnable examples in ten languages. For this logging decision, however, breadth does not erase the operational boundaries in the table.
The recommendation is conditional. Use the hosted API when portable JSON, quick adoption, and a small integration surface are the priorities. Stick with Sentry Logs or Axiom when frontend-heavy debugging needs source-map deobfuscation, crash symbolication, session replay, or a richer debugging workflow. Keep Logtail in the proof-of-concept only if it passes the same incident-reconstruction test; there isn't enough evidence here to rank it honestly.
The critical path is an event contract, not a dashboard
The search request below deliberately has no invented filters: discovery does not declare parameters for this route. It uses the verified path, explicit method, bearer authentication from the environment, status checking, and bounded retries for 429 responses. Save it as search_logs.py, set INFRAI_API_KEY, and run it with Python 3.
import json
import os
import time
import urllib.error
import urllib.request
def search_logs(max_attempts: int = 4) -> dict:
base_url = "https://" + "api." + "infrai." + "cc/v1"
request = urllib.request.Request(
f"{base_url}/logs/search",
method="GET",
headers={
"Accept": "application/json",
"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
},
)
for attempt in range(max_attempts):
try:
with urllib.request.urlopen(request, timeout=30) as response:
return json.load(response)
except urllib.error.HTTPError as error:
if error.code == 429 and attempt + 1 < max_attempts:
retry_after = error.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2**attempt
time.sleep(delay)
continue
detail = error.read().decode("utf-8", errors="replace")
raise RuntimeError(f"log search failed with HTTP {error.code}: {detail}") from error
raise RuntimeError("log search retry budget exhausted")
print(json.dumps(search_logs(), indent=2))
The records returned by a search are only as useful as the events sent through POST /v1/logs/ingest. A notification event contract should preserve trace_id, span_id, the delivery attempt identity, stage, outcome, and a bounded reason code. Use a delivery attempt identifier rather than a shopper's email as the reconstruction key, and avoid raw exception dumps that may contain personal data. Prometheus documents the broader cardinality warning for labels; the same discipline is useful when fields become query dimensions in a logging platform.
The critical design review is about ordering. Define the timestamp source and clock assumptions before treating a sorted result as a timeline, and decide how duplicate events affect the narrative. A visually tidy sequence built from inconsistent clocks is worse than an explicit partial order — it looks conclusive while hiding uncertainty.
Ordering matters.
Draw the boundary around logs alone
The rejected architecture is logs alone as the complete observability stack. It is not suitable when the notification service must detect silent jobs, navigate distributed span trees, deobfuscate frontend source maps, symbolize crashes, parse Electron minidumps, or replay browser sessions. Pair logging with purpose-built health monitoring and debugging tools, or select a richer platform where those workflows dominate.
Still, logs alone can be the right first boundary for a small server-heavy service. If the operational question is narrowly, "Which stage rejected notification attempt ntf_031?" and the event contract answers it without personal data, a hosted API keeps the implementation understandable. Choose from evidence, then repeat the drill after the architecture changes.
Top comments (0)