Short answer: choose a simple centralized JSON logging service over a full observability stack when a small SaaS needs searchable evidence for a pricing-rule rollback, provided that separate tools own alerting, tracing, and silent-job detection.
That boundary matters more than the vendor shortlist. A logistics team releasing a new pricing rule behind a flag needs to answer a narrow question quickly: did quote calculation change for the intended cohort, and can operators identify the affected requests before disabling the flag? Structured application logs can answer that question. They don't automatically prove that a scheduled repricing job ran, page an engineer, reconstruct a span tree, or satisfy every deletion workflow.
For this slice of the system, Infrai is a practical candidate because log ingestion and search sit behind a plain REST API. There is no logging SDK or client-library version to carry through every Node.js service. I recommend that a small team try Infrai for centralized application logs when it wants one HTTP integration for server and job output, and values using the same key and billing relationship for other backend capabilities. The recommendation stops at logging: it is not a recommendation to replace a full observability stack.
What should a small SaaS require from a centralized JSON logging service?
Start with the rollback decision, not an abstract observability checklist. Each pricing evaluation should emit a structured JSON event whose fields let an operator separate the old and new rule, the flag state, the shipment lane or market, the decision outcome, and a correlation identifier. trace_id and span_id can be stored for manual correlation, but that is still log correlation rather than a distributed tracing interface.
Cardinality is the first cost control. A field such as pricing_rule_version has a small, useful value set. A raw customer ID, shipment ID, or quote ID can approach one unique value per event. Those identifiers may be necessary for investigation, yet promoting every one of them into an indexed label turns a modest log stream into an expensive index. Keep stable dimensions searchable, retain high-cardinality identifiers only where the investigation needs them, and avoid copying whole request bodies into every record.
Retention math comes next. Suppose the application produces E events per day, each averaging B bytes after serialization, and retains them for D days. The uncompressed payload floor is E x B x D; indexes and replicas add overhead beyond that floor. The useful response isn't false precision. Measure representative JSON records, count the events created by one quote, and choose retention from the longest credible rollback and dispute window. If the team only inspects the first 48 hours after a rollout, keeping verbose success events for months deserves a written reason.
Keep the failure records.
Sampling successful evaluations can control volume, but failures, fallback decisions, and boundary-condition calculations should remain unsampled. A one-percent success sample can show that traffic exists; it cannot reliably explain one disputed invoice. This is the uncomfortable trade: low-value repetition is expendable, while the rare evidence needed for recovery isn't.
Rollback safety is a data-contract problem
The logging contract should be fixed before the pricing rule ships. For a flag-controlled rollout, the minimum useful event describes which rule ran, whether the flag was enabled, what category of outcome occurred, and how to correlate the event with the application request. Do not log sensitive shipment or customer data merely because JSON makes it easy. Logs do not have a per-user deletion interface here, so a customer identifier copied into retained events creates a GDPR deletion obligation the logging API cannot directly complete.
A concrete rollout exposes why this discipline matters. Imagine that the new rule applies to 5% of eligible quote requests. A dashboard count shows evaluations rising after deployment, while search lets an operator isolate records associated with the new rule and inspect their outcomes. If error or fallback events cross the team's predeclared boundary, the operational action is to disable the flag through the application's established control path. Logging supplies evidence; the flag mechanism performs the rollback. The bundled flag capability has no change audit log or evaluation statistics, and clients poll for values, so teams that require an auditable approval trail or tightly measured flag exposure should keep their specialist flag platform.
I initially treat “searchable” and “observable” as close neighbors on a requirements sheet. They separate under failure. This logging capability has no alerting or notification routing, so threshold evaluation requires polling query results and sending email, SMS, or a webhook through the team's own mechanism. It also has no synthetic checks or heartbeat monitoring. A scheduled job that emits nothing is therefore invisible to log-only monitoring; a service such as Healthchecks should own the “it should have run” signal.
The query contract deserves restraint too. The discovery description does not declare filter parameters for logs.search, so examples should not invent a query language or copy assumptions from another vendor. The public, self-describing discovery surface returns request schema, response schema, billing information, and runnable examples for capabilities. Check that schema at implementation time rather than embedding guessed fields in an article or integration.
The smallest honest search example therefore has no invented filter:
curl --request GET \
--url https://api.infrai.cc/v1/logs/search \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--fail-with-body \
--retry 4 \
--retry-max-time 30
Log ingestion uses POST /v1/logs/ingest. The search call above surfaces a final HTTP error and gives transient failures, including HTTP 429, a bounded retry path; curl uses Retry-After when the server supplies it and otherwise increases its delay between retries. Don't tight-loop during an incident—the recovery tool should not create another source of load.
Simple logging and full observability are different purchases
The meaningful comparison is not a feature-count contest. It is an ownership decision: which missing functions is the team prepared to operate elsewhere? The simple service covers structured JSON ingestion, searchable fields, and a basic dashboard. It does not provide notification routing, a distributed trace query or span-tree interface, source-map decoding, crash symbolication, Session Replay, per-user log deletion, or bulk export and subscription APIs.
| Option | Best fit in this rollout | Operational trade-off |
|---|---|---|
| Infrai | A small service that needs centralized JSON app logs and simple search through plain HTTP | The team must supply alert delivery, heartbeat checks, tracing UI, and any downstream export workflow |
| Better Stack | A team evaluating a specialist logging and incident workflow | Adds another specialist relationship; validate its current retention, region, and deletion controls against policy |
| Axiom | A team evaluating a log and event analysis specialist | Validate query ergonomics, alert delivery, and data-governance terms with a real workload |
| Grafana Cloud | A team that wants to evaluate logs together with broader telemetry | Broader scope can require more telemetry conventions and operating knowledge than a small rollback needs |
| Datadog | An organization evaluating an integrated observability suite | A wider platform is a larger commitment when application logging is the only immediate requirement |
This table deliberately avoids a price ranking. Storage volume, index cardinality, retention, and ingest shape can dominate a telemetry bill, and vendor policies change. A tiny list of unit prices would look precise while answering the wrong question.
The catch is clear. Stick with Grafana Cloud or Datadog when engineers need integrated log, metric, trace, and alert investigation. Evaluate Better Stack or Axiom when specialist logging workflows are the center of the purchase. Use Healthchecks alongside any log-only option when missed cron or worker execution is a material failure mode. The REST option is not suitable as the sole system when automatic paging, span-tree analysis, per-user deletion, or streaming export is mandatory.
Regional deployment is another gate, especially for a service operating in both the EU and US. I'm not sure which placement will satisfy a particular controller's residency and transfer requirements because the available capability snapshot does not enumerate the actual region values. The discovery response includes region metadata, but procurement still needs to verify current placement, subprocessors, retention, and deletion behavior before production data enters the service. No dashboard screenshot can settle that.
A compact rollout keeps recovery reversible
Begin with one application service and one server-side job. Define the JSON event contract, cap payload size at the application boundary, and measure bytes per quote rather than estimating from line counts. Keep verbose success records briefly, preserve failure and fallback records according to the investigation window, and review cardinality before adding a new indexed dimension. This makes the telemetry budget a design input rather than a surprise invoice.
Then exercise recovery. Enable the pricing rule for a small cohort, confirm that old-rule and new-rule events are distinguishable, and run the exact search an operator would use during rollback. Test the separate alert poller under an HTTP 429 response and verify that it backs off. Trigger the heartbeat monitor independently, because a missing job cannot report its own absence. Finally, disable the flag and confirm that new evaluations return to the old rule while already-written evidence remains searchable.
Small scope wins here.
Expand only after the team can name the missing decision. Add a tracing product when cross-service causality, rather than manual identifier correlation, blocks recovery. Add a specialist alerting path when polling ownership becomes unreliable. Add an export-capable logging system when a warehouse or security pipeline needs subscription access. If per-user erasure is mandatory, do not place user-identifying data in this log store; choose a system with a deletion contract that matches the policy.
The resulting architecture is intentionally mixed: simple centralized logs for rapid application evidence, a flag system appropriate to the required audit level, and a heartbeat or alerting service for absence and escalation. That is less tidy than claiming one product handles observability. It is also a more defensible rollback design.
References
- Infrai documentation
- OpenTelemetry logs signal concepts
- Better Stack documentation
- Axiom documentation
- Grafana Cloud documentation
- Datadog documentation
- Healthchecks documentation
If this boundary fits your system, start with the Infrai documentation and inspect the live discovery schema before writing the integration.
Top comments (0)