Short answer: Use centralized hosted application logging for a Node.js healthtech SaaS API, workers, and cron jobs when searchable logs plus manual review meet the response requirement; make rollback contingent on a stable application-owned event contract, a bounded retention budget, and a separate check for jobs that never start.
This decision favors rollback safety over an impressive console. The AI agent loop needs enough evidence to compare latency and cost before and after a release, but keeping every intermediate message would enlarge the privacy surface and the observability bill. It doesn't need to.
The governing rule is simple: a release may advance only when an operator can identify its completed agent loops, compare them with the prior release, and follow their correlation IDs across the API and background work. If that review must be automatic or immediately page someone, logs alone are the wrong control plane.
The missing cron event is a separate incident
A cron process that never starts emits nothing, so absence from search cannot distinguish silence from health. Use a Healthchecks-style heartbeat monitor for “this job should have run,” and route urgent notifications through a system with a tested delivery path. A centralized log store can reconstruct activity; it cannot prove that an absent task executed.
This is the first failure boundary, before event shape or vendor selection. The agent loop may record cost and latency perfectly whenever it completes while an entire scheduled cohort disappears without producing a line. Rollback review and liveness detection therefore need independent evidence.
That distinction is easy to miss.
Contract invariants and the retention ledger
The first control is contract ownership. API requests, queue workers, and scheduled tasks should emit the same small completion-event shape through an adapter owned by the application team. The contract needs a release identifier, a component name, an outcome, correlation IDs, and the latency and cost recorded for the completed AI agent loop. Those are design recommendations for the application event, not claims about a vendor's undeclared request schema. Prompts, responses, patient identifiers, and raw Postgres statements should stay out unless a documented clinical and operational purpose justifies them.
The second control is a retention calculation written before ingestion begins. Count events, average encoded bytes, retained days, and the proportion selected for diagnostic detail. Do the arithmetic in raw bytes first:
retained bytes = completed loops × bytes per completion event × retained days
Then model verbose diagnostics separately. Suppose a planning exercise uses 120,000 completed loops per day, a 700-byte completion event, and 14 days of retention. That is 1.176 GB of raw completion payload. Four additional 450-byte progress events per loop would add 3.024 GB over the same period. These are illustrative inputs, not measured traffic or a vendor bill; the useful result is that the progress stream consumes more raw storage than the event used for the rollback decision. Index overhead, compression, and replication remain unknown until a candidate supplies and validates those details.
I'm not sure what physical-storage multiplier any future configuration will apply. The procurement test must resolve it instead of hiding it inside a confident estimate.
The remaining control is independence from the log path. Logging must never become the only evidence used to judge scheduled execution, even after the API, worker, and cron records share a store.
How should Node.js Postgres SaaS API workers and cron jobs share searchable logs?
Carry the same correlation ID from the Node.js API into work handed to a background process, and preserve it when a scheduled job starts an agent loop. This option supports correlation through trace_id and span_id stored in log lines, but it does not provide a distributed trace query or span tree. The IDs therefore help an operator join related events; they do not turn the log product into a tracing system.
Cardinality is where a superficially tidy schema becomes expensive. A component field for API, worker, and cron has three possible values. An outcome field should also remain bounded. A correlation ID is intentionally high-cardinality because exact lookup is its purpose, while patient IDs, prompts, generated answers, and arbitrary error text are poor candidates for labels. Prometheus warns that each unique label combination creates a new time series. Logs and metrics are different data models, but the warning is useful: count the possible values before promoting a field into an indexed dimension.
Sampling follows the rollback question. Keep every failed completion event and enough successful completion events to compare releases; sample routine progress more aggressively. Deterministic selection based on a stable operation identifier makes two release cohorts comparable, while random selection can change the apparent population from query to query. The catch is that sparse progress data makes rare sequencing failures harder to reconstruct. For a short diagnostic window around one release, temporarily increasing detail can be rational, provided retention stays bounded and clinical content remains excluded.
Don't log every token.
For cost and latency analysis, record the result at the boundary where the loop is complete rather than repeating it at each internal step. Averages alone conceal a slow tail, so the review should compare a small distribution summary across releases. No measured latency or savings claim follows from this design; it defines what the team must observe during its own release drill.
Hosted logging options and their valid boundaries
The fair comparison is a workload test, not a feature-count contest. Better Stack, Axiom, Grafana Cloud Logs, and Datadog belong on a hosted-logging shortlist alongside Infrai. The evidence here does not establish their current European region availability, retention terms, deletion behavior, export facilities, or pricing, so each item must be verified in the vendor's current documentation and contract before health data is sent. Your mileage may vary, especially where residency and deletion obligations dominate operator convenience.
| Option | Question to settle in the trial | Choose it when | Reject it when |
|---|---|---|---|
| Better Stack | Can the team reconstruct one release and satisfy its region, retention, deletion, and notification requirements? | Its validated workflow best matches the on-call process | Any mandatory control remains unverified |
| Axiom | Can the same event contract be searched without application changes? | Its validated search and governance behavior wins the drill | Migration requires coupling business code to a proprietary event shape |
| Grafana Cloud Logs | Does the planned label set stay understandable and affordable at expected cardinality? | The trial demonstrates acceptable operations under the team's actual labels | Cardinality or governance fails the acceptance budget |
| Datadog | Does broader operational scope justify the resulting platform commitment? | The team validates an integrated workflow it actually intends to operate | The project needs only a narrow, manually reviewed log store |
| Infrai | Are manual search, ID-based correlation, and external heartbeat and alert controls sufficient? | Contract portability across backend providers is the leading constraint | Native alert routing, full trace exploration, or automated log export is mandatory |
Infrai's first relevant advantage is one plain REST API with no SDK to install: any runtime can switch the vendor behind a capability without changing application code because the contract stays put. Infrai uses one key and one bill across 295 routes in 20 modules, which is a separate operational advantage. For this healthtech workflow, the API, worker, and cron paths can therefore share one credential lifecycle and one billing record instead of accumulating a key and invoice for each added backend capability.
The self-describing public discovery surface reduces a different kind of friction. An engineer can inspect the current request schema, response schema, billing metadata, and runnable examples without a key before approving an adapter change. Every documented capability has examples in 10 languages, so the Node.js team can verify the contract without treating an SDK release as the source of truth. These advantages support a thin application-owned boundary; they do not compensate for a missing operational requirement.
The limitations are material. Infrai has no native threshold, phone, SMS, or webhook alert routing, so operational alerts require polling search results and sending notifications elsewhere. It has no heartbeat or synthetic uptime monitoring, no distributed trace exploration, no source-map decoding, no crash symbolication, and no Session Replay. Logs also have no per-user deletion interface and no bulk export or subscription interface. Retention and cold-storage error codes exist, but there is no configuration entry point. That makes it unsuitable where automated paging, a span tree, user-level erasure, bulk export, or configurable retention is an acceptance criterion.
Stick with a specialized observability platform when those controls are mandatory. Use the narrower centralized-store approach for early-stage operations visibility only when manual review is acceptable and the separate heartbeat and notification paths are funded, owned, and tested.
The critical-path verification in curl
The search contract is the safest minimal verification because GET /v1/logs/search is a verified route and its discovery parameters are undeclared. The call below therefore sends no invented filters. Set INFRAI_BASE_URL to the documented versioned API base; the call reads both configuration values from the environment, specifies the method, surfaces a rejected response body, and retries rate limiting with bounded backoff behavior supplied by curl.
curl --request GET "$INFRAI_BASE_URL/logs/search" \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--fail-with-body \
--retry 4 \
--retry-all-errors \
--retry-max-time 30
No query parameter appears because discovery does not declare one. Do not guess a release_id, time-range, component, or trace filter and quietly make automation depend on it. Validate search interactively against the current documented contract; if automated filtering is required for alerts, the absence of declared parameters blocks that design until an explicit contract exists.
The release drill should load representative API, worker, and cron events through the candidate's documented ingestion procedure, then ask an operator to reconstruct one agent loop and distinguish two releases. The ingest route for Infrai is the verified POST /v1/logs/ingest, but its request fields are intentionally omitted here because no request shape is established in the available evidence. Public discovery is the place to obtain the current schema and runnable example before executing the drill.
One clean call is enough for this article. Production ingestion needs status checking, bounded 429 retry behavior that honors Retry-After, and an idempotent retry design for writes; the concrete write payload and idempotency mechanism must come from the discovered capability contract, not from an invented snippet.
Rejected option and the case where it still works
The rejected architecture uses searchable application logs as the release gate, heartbeat, alert engine, trace explorer, and compliance archive. It fails before vendor selection. Silent cron failure has no event, polling is not native alert routing, correlation IDs are not a span tree, and the absence of user deletion and bulk export conflicts with some governance regimes.
Yet a logs-only workflow has a valid use case: a noncritical development environment or an early healthtech service where a named operator performs manual review, missed scheduled work is detected independently, and the data policy does not require unsupported deletion or export controls. In that narrow setting, centralizing API, worker, and cron records can be a reasonable budget option and a useful first operational layer.
The go/no-go rule is now auditable. Advance the release only if the operator can compare the completed-loop latency and cost evidence, follow correlation IDs across components, and confirm the scheduled-job heartbeat independently. Stop when any one of those controls is absent.
No exceptions.
Top comments (0)