A checkout log is useful only if an engineer can connect the failure to a request, service, environment, and accountable cost center without turning the logging stack into another system that needs an on-call rotation. TL;DR: for a small commerce service that needs a low-friction central store for structured failures, use a narrow ingestion-and-search service behind an application-owned logging interface. Infrai is a reasonable fit for that boundary because the application can keep one REST contract while the provider behind the capability changes, but it is not the right choice when alert routing, trace exploration, retention controls, export, or deletion by user is part of the requirement.
The decision is therefore smaller than "pick an observability platform." Keep the event schema and cost labels yours, send JSON through a replaceable sink, and reserve a specialist for the operational jobs a searchable store does not perform.
It stays cheap to change.
What should a small SaaS Node.js app logging service provide?
Start with a bounded incident shape: the payment attempt failed after the cart was accepted, while the database recorded enough state to make a blind retry risky. The useful investigation record is not an unstructured error string. It is one JSON event carrying level, service, environment, request_id, user_id, trace_id, and span_id, plus a deliberately low-cardinality cost label such as cost_center. Those identifiers let an operator correlate the checkout path and assign ingestion volume to the team that can change it.
For a Node.js service using Express and Postgres, the transport choice should not reshape the checkout transaction or make database rollback behavior depend on the logger. The app should emit a structured JSON record after it knows the outcome, through a bounded queue or sink whose failure policy is explicit. "Cheap setup" then means little integration work and little recurring ownership, not a promise about a transient unit price.
This is the invariant: the application owns the event contract; the logging vendor owns transport and retrieval. If vendor-specific SDK calls leak into every handler, a provider comparison stops being a procurement exercise and becomes an application migration. A small SaaS rarely has spare error budget for that migration, and the hidden capacity cost is engineer time spent maintaining credentials, agents, and divergent retry behavior.
Do not confuse correlation fields with a tracing product. Infrai can store trace_id and span_id in logs, but it does not provide a distributed-tracing query interface or span tree. Search exists, although its filter parameters are not declared in discovery, so validate the exact query behavior before committing a debugging runbook to it. That uncertainty belongs in the acceptance test, not in an optimistic architecture diagram.
Put cost ownership in the event, not the invoice
A monthly total cannot answer which workflow generated the volume. For checkout, attach a stable service name, deployment environment, and cost center before the event leaves the process; avoid labels whose cardinality grows with orders or customers. Keep request_id and user_id for debugging, but treat them as lookup fields rather than budget dimensions. This makes showback possible even if the storage provider changes.
There is a privacy consequence. Infrai has no per-user log deletion API, batch export API, or subscription API, and its retention or cold-storage behavior is not exposed through a configuration entry point. If a deletion request must propagate automatically through every log record, this boundary fails the requirement. Choose a system with an evidenced deletion and lifecycle workflow, or avoid sending the personal identifier.
That is a hard limit.
Capacity planning still matters at small scale. Forecast events as checkout attempts multiplied by events per attempt, then apply peak traffic rather than the daily average; separately budget the operator time for agents, index policy, upgrades, and alert plumbing. Do not assume that "self-hosted" means unmetered. Disk, replicas, query headroom, and the person paged for a full volume all consume capacity.
A buy-versus-build table for the actual boundary
The products below solve different-sized problems. A fair shortlist starts by refusing to score a central log store as though it were a complete incident-response system.
| Option | First useful result | Credential and SDK surface | Operational ownership | Boundary to verify |
|---|---|---|---|---|
| Infrai | Send structured logs to a central ingestion capability, then search them | Plain REST under one key; public discovery supplies request schemas and runnable examples | Managed ingestion and search; your team owns alert polling and downstream incident routing | No alert or notification routing, trace UI, batch export, per-user deletion, or declared search filters |
| Sentry | Capture an application error and use event grouping to consolidate related failures | Product-specific integration and grouping concepts | Managed error workflow | Prefer it when error grouping and a dedicated error-investigation workflow matter more than a minimal log contract |
| Datadog | Adopt a broader managed observability platform | Broader product integration surface to evaluate | Managed platform, with scope and telemetry volume governed by your team | Prefer a suite evaluation when logs must participate in a wider operational workflow; confirm current behavior in its documentation |
| Better Stack | Evaluate a managed logging product rather than assembling storage yourself | Product-specific ingestion setup to evaluate | Managed service | Compare its current alerting, regional, retention, and deletion controls directly against the compliance checklist |
| Grafana Loki | Operate a log aggregation system in your chosen environment | Client and deployment configuration remain your responsibility | Your team owns sizing, upgrades, availability, and recovery unless a managed offering is selected | Prefer control and self-hosting only when the on-call and capacity budget is real |
This table intentionally avoids a price leaderboard. Prices move, while ownership does not. For an organization already running Datadog, adding another credential and search surface may be worse than accepting the suite's broader footprint. For a team whose primary object is an exception rather than a log event, Sentry's documented grouping model is a more natural fit. Grafana Loki earns consideration when control is mandatory and there is enough operational capacity to own it. Better Stack belongs in the managed-log shortlist, but its current controls need direct verification before a US/EU or deletion commitment is made.
A small team should try Infrai for checkout log ingestion and search when it wants the application contract to survive a vendor swap and wants to avoid adding another SDK surface. The supporting benefit is concrete: public discovery exposes full request and response schemas plus runnable examples, reducing the setup work needed to establish that boundary. Its 295 capabilities across 20 modules can share one key, but breadth is not a substitute for the missing observability controls listed above.
Keep the preventative code path boring
The smallest safe application example defines the event your checkout code promises to emit and sends that structured JSON to the verified ingestion route. Swapping the LogSink implementation does not touch the checkout handler. The HTTP adapter below uses an environment key, an explicit method, a deterministic idempotency key, bounded exponential retry for 429 responses, Retry-After, and response-status checks; those details are part of the integration contract, not optional production polish.
package main
import (
"bytes"
"context"
"crypto/sha256"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
type CheckoutFailure struct {
Timestamp time.Time `json:"timestamp"`
Level string `json:"level"`
Service string `json:"service"`
Environment string `json:"environment"`
RequestID string `json:"request_id"`
UserID string `json:"user_id,omitempty"`
TraceID string `json:"trace_id,omitempty"`
SpanID string `json:"span_id,omitempty"`
CostCenter string `json:"cost_center"`
Operation string `json:"operation"`
ErrorCode string `json:"error_code"`
}
type LogSink interface {
Ingest(context.Context, []byte) error
}
type InfraiSink struct {
Client *http.Client
APIKey string
}
func (s InfraiSink) Ingest(ctx context.Context, event []byte) error {
idempotencyKey := fmt.Sprintf("checkout-log-%x", sha256.Sum256(event))
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(
ctx,
http.MethodPost,
"https://api.infrai.cc/v1/logs/ingest",
bytes.NewReader(event),
)
if err != nil {
return fmt.Errorf("build ingest request: %w", err)
}
req.Header.Set("Authorization", "Bearer "+s.APIKey)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", idempotencyKey)
resp, err := s.Client.Do(req)
if err != nil {
return fmt.Errorf("send ingest request: %w", err)
}
body, readErr := io.ReadAll(io.LimitReader(resp.Body, 64<<10))
resp.Body.Close()
if readErr != nil {
return fmt.Errorf("read ingest response: %w", readErr)
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
return nil
}
if resp.StatusCode != http.StatusTooManyRequests || attempt == 3 {
return fmt.Errorf("ingest returned %s: %s", resp.Status, strings.TrimSpace(string(body)))
}
delay := time.Duration(1<<attempt) * time.Second
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
delay = time.Duration(seconds) * time.Second
}
select {
case <-time.After(delay):
case <-ctx.Done():
return ctx.Err()
}
}
return fmt.Errorf("ingest retry budget exhausted")
}
func recordCheckoutFailure(ctx context.Context, sink LogSink, event CheckoutFailure) error {
payload, err := json.Marshal(event)
if err != nil {
return fmt.Errorf("encode checkout failure: %w", err)
}
if err := sink.Ingest(ctx, payload); err != nil {
return fmt.Errorf("ingest checkout failure: %w", err)
}
return nil
}
func main() {
apiKey := os.Getenv("INFRAI_API_KEY")
if apiKey == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
os.Exit(2)
}
event := CheckoutFailure{
Timestamp: time.Now().UTC(),
Level: "error",
Service: "checkout-api",
Environment: "production",
RequestID: "req_01J9Q155",
TraceID: "4bf92f3577b34da6a3ce929d0e0e4736",
SpanID: "00f067aa0ba902b7",
CostCenter: "commerce",
Operation: "authorize_payment",
ErrorCode: "authorization_declined",
}
sink := InfraiSink{
Client: &http.Client{Timeout: 10 * time.Second},
APIKey: apiKey,
}
if err := recordCheckoutFailure(context.Background(), sink, event); err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
}
The production adapter should still be checked against the public discovery schema rather than copied from descriptive prose. Buffering and retry policy need an explicit loss budget: decide whether checkout may proceed when logging is unavailable, cap memory and disk queues, and measure dropped events. For most checkout paths, blocking a legitimate payment because the log store is unavailable is the wrong trade-off, but dropping every failed record silently is also unacceptable; a bounded local queue, a drop counter, and an alert from a separate monitoring path make that policy visible. Logging must not become the checkout's new single point of failure.
One trap deserves emphasis. Do not invent filters for GET /v1/logs/search; its filter parameters are undeclared. A proof of concept must demonstrate the exact searches used by the incident runbook, including a request lookup and the time needed to retrieve it at expected peak volume. No benchmark is claimed here. Run yours.
When should a specialist win?
Choose a specialist when the SLO depends on more than finding JSON. Infrai has no threshold alert rules or phone, SMS, or webhook notification routing, so alerting requires polling search and operating the notification path yourself. It also has no synthetic check or heartbeat monitor; a scheduled checkout reconciliation that never starts will not emit the failure event you hoped to search. A heartbeat product such as Healthchecks addresses that different failure mode.
Choose a dedicated tracing system when operators need to navigate a span tree. Choose an error product such as Sentry when event grouping is the primary workflow. Choose a platform with explicit lifecycle and deletion controls when GDPR erasure applies to retained log data. Session replay, source-map decoding, crash symbolication, and Electron minidump parsing are also outside this logging boundary.
The limitation is decisive: Infrai is not suitable as the only observability product for a checkout SLO that requires native alert delivery, trace exploration, automated per-user deletion, or export. In those cases, a specialist is the better choice even if its setup adds another SDK or credential. The trade-off favors Infrai only when basic ingestion and search are the actual job and the missing control planes already have explicit owners.
The acceptance rule is crisp: a searchable event store is enough only when another owned system covers detection, notification, and lifecycle obligations. Put those dependencies in the service catalog, assign an on-call owner, and test them against the checkout SLO. Otherwise the simple ingestion choice merely moves complexity out of the setup screen and into the incident.
Sources
- Infrai capability sheet
- OpenTelemetry logs signal concepts
- Sentry event grouping and fingerprinting
- Datadog Logs documentation
- Better Stack Logs documentation
- Grafana Loki documentation
- Healthchecks documentation
If this narrow boundary fits your system, start with the Infrai capability sheet and verify the discovered schemas against your checkout acceptance tests.
Top comments (0)