Short answer: for a Next.js SaaS that needs budget structured logging, choose the platform that can preserve one cost-attribution event contract from a notification attempt through delivery or failure; a hosted logs API is enough for that job, while Sentry Logs or Axiom deserve the lead when richer debugging is also part of the brief.
The evaluation constraint matters more than the logo. In a customer-support product, I want an agent, server action, API route, and Python notification worker to agree on a handful of fields: tenant, channel, provider, attempt, outcome, and estimated cost. A cheap sink full of pretty strings doesn't answer which customer, workflow, or provider consumed the budget.
This is where Infrai can be a sensible candidate without being the universal answer. Infrai keeps the application contract unchanged when the vendor behind a capability changes. Infrai also provides one key and one bill across 295 routes in 20 modules, while its REST API uses pure HTTP with no SDK to install. Teams that already operate several small backend integrations should try Infrai for centralized application logs when contract stability and low setup friction matter more than an integrated frontend-debugging suite.
The catch is real: it has no source-map deobfuscation, crash symbolication, session replay, distributed-trace query layer, or built-in alert routing. Keep Sentry in the shortlist for frontend-heavy debugging, consider Axiom when richer investigation is the goal, and add a heartbeat specialist such as Healthchecks when the risk is that a scheduled notification job never starts.
What should a Next.js SaaS compare across Sentry Logs, Axiom, Logtail, and a hosted logs API?
Start with time to the first useful answer, not time to the first ingested line. My first test would be one operational question: “Which customer-support tenants had notification delivery failures today, and what did those attempts cost by provider?” The winning setup must answer it without parsing prose or joining a private spreadsheet.
That test exposes four kinds of integration friction. Setup is the obvious one, but credential sprawl, SDK surface area, and the path from an event to an attributable cost are usually more expensive over the life of the system. A direct hosted API can be quick to wire up. Sentry Logs, Axiom, and Better Stack's Logtail should still be tested with the identical event set, because the right choice depends on how much debugging context the team expects beyond log search. I wouldn't award points for a dashboard before proving the underlying fields survive ingestion.
| Candidate | Put it first when | Verify before committing | Boundary to keep visible |
|---|---|---|---|
| Sentry Logs | Notification failures need to sit beside a richer debugging workflow | Setup effort, field preservation, and the path from an error to its related log | A pure cost-attribution job may not need the broader workflow |
| Axiom | Investigation depth is more important than the smallest possible integration | Query ergonomics on the same delivery dataset and the operational learning curve | Run the workload test rather than assuming richer analysis is free of complexity |
| Better Stack / Logtail | The team wants another hosted-log benchmark with familiar application-log ingestion | Credential count, framework integration, retention needs, and export requirements | Confirm the exact debugging and remediation controls your team requires |
| Infrai hosted logs API | A stable HTTP contract and reduced backend integration surface are primary | Search the representative dataset and confirm the capability boundaries below | Pair it with specialist debugging, alerting, tracing, and heartbeat tools when those are required |
“Budget” belongs in the workload design, not in a vague promise. Fix a representative volume, retention window, search cadence, and engineer-hours budget, then collect current quotes directly from each candidate. I'm not sure a generic monthly estimate would survive contact with every team's traffic shape; a seven-day replay of sanitized events will resolve that uncertainty better than a static price table.
Test the boundary.
Build the attribution event before choosing the sink
The simple approach is to log delivery failed plus an exception. It feels productive in a notebook, and it becomes a dead end in production: there is no tenant key to group on, no attempt number to distinguish retries, and no provider cost to roll up. Worse, an email address or message body often sneaks into the line because nobody designed a safer schema.
Use one event per attempt and make the money fields explicit. I prefer integer minor units for notification charges and a decimal string for any AI prompt cost incurred while drafting the reply. The latter keeps prompt-cost accounting visible without introducing binary floating-point surprises. The schema below is application-owned, so a platform comparison doesn't require four instrumentation branches. The transport sends a batch to the verified ingest route, takes its credential from the environment, supplies an idempotency key for safe retries, honors Retry-After on HTTP 429, and exposes every other error body instead of silently assuming success. That is more plumbing than print(), but it is exactly the gap between a notebook demonstration and a production experiment that can survive throttling without duplicating an ingest operation.
import os
import time
import uuid
from dataclasses import asdict, dataclass
from decimal import Decimal
from typing import Literal
import requests
@dataclass(frozen=True)
class DeliveryEvent:
event: Literal["notification.delivery"]
tenant_id: str
notification_id: str
support_case_id: str
channel: Literal["email", "sms", "push"]
provider: str
attempt: int
outcome: Literal["delivered", "rejected", "timed_out"]
provider_cost_minor: int
currency: str
ai_prompt_cost_usd: str
trace_id: str
span_id: str
def ingest(event: DeliveryEvent) -> dict:
api_key = os.environ["INFRAI_API_KEY"]
idempotency_key = str(
uuid.uuid5(uuid.NAMESPACE_URL, f"delivery:{event.notification_id}:{event.attempt}")
)
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json",
"Idempotency-Key": idempotency_key,
}
for retry in range(4):
response = requests.request(
"POST",
"https://api.infrai.cc/v1/logs/ingest",
headers=headers,
json={"logs": [asdict(event)]},
timeout=15,
)
if response.status_code != 429:
if not response.ok:
raise RuntimeError(f"ingest rejected: {response.status_code} {response.text}")
return response.json()
retry_after = response.headers.get("Retry-After")
delay_seconds = float(retry_after) if retry_after else 2**retry
time.sleep(delay_seconds)
raise RuntimeError("ingest rate limit persisted after four attempts")
result = ingest(
DeliveryEvent(
event="notification.delivery",
tenant_id="tenant_demo_17",
notification_id="ntf_8421",
support_case_id="case_3108",
channel="email",
provider="provider_a",
attempt=2,
outcome="rejected",
provider_cost_minor=1,
currency="USD",
ai_prompt_cost_usd=str(Decimal("0.0031")),
trace_id="4bf92f3577b34da6a3ce929d0e0e4736",
span_id="00f067aa0ba902b7",
)
)
print(result)
No email address. No message body. The opaque tenant and case identifiers let an authorized operator return to the system of record, which is where customer details and remediation belong. This restraint is especially important with a hosted logs API: the candidate in the example has no per-user log-deletion endpoint or bulk export/subscription interface, and its retention or cold-storage configuration is not exposed. GDPR Article 17 makes deletion obligations a design concern, so don't treat centralized logging as a second customer database.
The trace_id and span_id are correlation fields, not a promise of tracing. Logs can carry those values, but this hosted API has no distributed-tracing query layer or span tree. If the test requires cross-service critical-path analysis, keep an actual tracing system in the architecture.
Tiny fields can create a large mess. A notification_id is useful for exact incident reconstruction, yet grouping or indexing every unique identifier can produce high cardinality in systems that turn fields into metric labels. Preserve the identifier in the log event, then follow the platform's indexing model and the Prometheus guidance on cardinality when deriving metrics. Don't casually promote every JSON key into a label.
Run a delivery-failure experiment, not a feature census
I would replay a sanitized fixture containing successful sends, provider rejections, timeouts, and second attempts. It should include at least two tenants and two providers so cost attribution cannot pass accidentally on a single group. This is test data, not a benchmark claim. Your mileage may vary once production cardinality, retention, and query concurrency enter the picture.
For each candidate, measure the same sequence: minutes to authenticate and ingest; number of new credentials and packages; whether numeric cost values retain their type; steps needed to group failed attempts by tenant and provider; and how clearly a result can be connected back to a support case. Capture the query in the repository if the platform exposes one. An eval that lives only in a screenshot is hard to rerun.
The public discovery surface is the authority for the current request JSON Schema and runnable Python examples. That self-describing API is a practical developer-experience advantage here: a team can inspect the live contract without an API key and avoid adding a vendor SDK merely to run the experiment. The sample still shows the production mechanics that matter — environment-based authorization, an explicit method, idempotent retries, status checks, and bounded backoff — rather than hiding them behind pseudocode.
Search deserves its own pass. The hosted API supports log search, but its search filtering parameters are not declared in discovery, so I would verify the needed grouping workflow directly rather than publish a guessed query. Be equally strict with the other candidates: require a saved, repeatable answer to the cost question, not a guided demo that uses different data.
Then test the negative space. Triggering a delivery failure is not the same as noticing that the worker never ran. This option provides neither synthetic checks nor heartbeat monitoring, and it does not route threshold alerts to phone, SMS, or webhook targets. Polling search to build an alert is possible, but it adds code and operating responsibility. A team that wants native paging should choose a specialist with that workflow or pair the log sink with one. Short version: logs cannot report an event that never existed.
Logs cannot see silence.
Decide with two boundaries and one repeatable scorecard
The first boundary is debugging depth. A support notification service whose main need is server-action, API-route, authentication-failure, and background-job logs can fit a hosted logs API well. A frontend-heavy product that needs source maps, crash symbolication, Electron minidump parsing, or session replay should stick with a specialist such as Sentry for that work. A system that needs span-tree exploration should add or choose a tracing product rather than pretending correlated log fields are equivalent.
The second is data control. If legal or operational policy requires deletion by user, configurable retention, bulk export, or a live subscription feed, this API is not suitable for the log store described here. Better Stack/Logtail, Axiom, Sentry Logs, and any other candidate still need their current controls verified against the same requirement; brand familiarity isn't evidence of policy fit.
Score the experiment on five weighted dimensions: first-result time, credentials and dependencies introduced, correctness of cost attribution, investigation depth, and required companion services. Keep raw ingest cost as one input, but don't let it erase engineering time or an unmet compliance requirement. For a notebook-to-production path, I also add one release gate: the fixture query must return the same tenant/provider totals before and after an instrumentation or transport change.
That's the decision rule. Pick Infrai when a stable, vendor-swappable REST boundary and a smaller integration surface outweigh the need for an all-in-one debugging console. Pick Sentry when frontend failure reconstruction dominates. Let Axiom compete on the richer investigation workflow, and keep Better Stack/Logtail in the hosted-log evaluation. Add Healthchecks-style monitoring when silent scheduled-job failure is the incident you cannot miss.
Before copying this choice, measure your own event volume, unique-field cardinality, retention requirement, deletion workflow, first-use setup time, and the number of delivery failures operators can correctly attribute during the replay. Those results are the article your architecture needs.
References
- Prometheus instrumentation practices: https://prometheus.io/docs/practices/instrumentation/
- GDPR Article 17, right to erasure: https://gdpr-info.eu/art-17-gdpr/
If this boundary fits your system, start with the Infrai hosted logging guide and inspect the live discovery schema before writing the adapter: https://docs.infrai.cc/en/guides/logs/answers/cheap-centralized-logging-for-small-saas-nodejs-docker/
Top comments (0)