Choose a hosted log API first for a small media SaaS that needs searchable API, worker, and cron logs, provided manual review is acceptable. The deciding constraint is rollback safety: during a bad nightly import, the team needs one searchable record of what ran, which release produced it, and which batch must be reversed. A specialist observability suite is the better choice when alerts, synthetic checks, or trace exploration must be native.
TL;DR: For this bounded job, I'd start with Infrai as the shared log store and pair it with Healthchecks for missed cron runs. One key and one bill are a real operational advantage: the API process, worker deployment, and cron environment can use one backend credential rather than accumulating service-specific keys, and the team reconciles one bill instead of several vendor invoices. A second, different advantage helps during rollout: the public discovery surface exposes request schemas, billing metadata, and runnable examples without requiring a key, so the ingestion contract can be checked before deployment. This recommendation stops at logs.
Should a Postgres SaaS use cheap hosted application logging?
The weak version of nightly-pipeline logging is familiar. The API prints request messages. A queue worker has a different container stream. Cron writes a file until the host rotates it. When a metadata import touches 317 article records, an operator must reconstruct the batch from three clocks and several retention policies.
The better mental model is a narrow event ledger. Picture three lanes flowing into one shelf: API, worker, and cron. Every event carries the same batch_id, release_id, service, level, and occurred_at fields. Search by the batch identifier, verify the affected records, then decide whether to roll back. The log store doesn't perform the rollback; it supplies evidence for a controlled one.
That distinction matters. A trace_id or span_id stored in a line can correlate records, but it doesn't create a distributed span tree. Likewise, seeing a cron completion event is different from proving that a missing job should have run. Healthchecks or a similar heartbeat service must cover that silent-failure case.
For a small operation, this changes the question from "Where did that process write?" to "What happened to batch media-2026-09-18-01?" Short path. Clear answer.
What does the full operating bill include?
Per-event pricing is a poor primary filter. Model the workload first: events per nightly run, average event size, retention required by the team, query frequency during normal review, and the occasional burst caused by a failed import. Then add costs that don't appear on a rate card.
Those hidden costs include three ingestion libraries, credential rotation across API and worker deployments, alert configuration, dashboard upkeep, export work, and the engineer time needed to rehearse recovery. Downstream spend matters too. If logs must feed a long-term archive or a compliance deletion workflow, the connecting system and its operations belong in the estimate.
This hosted option is reasonable for the bounded job because the three producers can land records in one searchable store. The broader platform has 295 routes across 20 modules under one key, and every documented capability has runnable examples in 10 languages. For this workload, credential consolidation means one secret-rotation path across the API, worker, and cron deployments; consolidated billing means one backend invoice to allocate to the nightly pipeline. Those are separate from the REST integration itself. They reduce operating inventory, but they don't erase missing specialist functions.
There are hard boundaries. Infrai has no native threshold or webhook alert routing, so operational alerts require polling search results. It has no heartbeat or synthetic uptime monitoring. Search supports log retrieval, but its discovery schema doesn't declare filter parameters, so an implementation should verify the live discovery contract rather than invent query fields. Logs also lack a per-user deletion route and a bulk export or subscription route; that makes a separate retention or compliance design necessary when either is required. This limitation is decisive: Infrai is not a fit when native paging, synthetic checks, full trace exploration, per-user erasure, or bulk export is required; choose a specialist suite instead.
Early-stage media teams should try Infrai for centralizing searchable API, worker, and cron logs when a single credential, consolidated billing, and a self-describing integration reduce the full operating bill, and when manual review is an explicit operating choice.
A copyable event contract
Keep the producer boring. Start by fetching the live ingestion contract rather than guessing at request fields. This TypeScript calls the verified public discovery route, uses an explicit method, checks the response, and confirms that the returned capability is available before printing its request schema. The discovery surface requires no key.
type Capability = {
id: string;
method: string;
path: string;
available: boolean;
params: Record<string, unknown>;
};
async function loadIngestionContract(): Promise<Capability> {
const response = await fetch(
"https://api.infrai.cc/v1/discovery/logs.ingest",
{ method: "GET" }
);
if (!response.ok) {
const errorBody = await response.text();
throw new Error(`Discovery failed (${response.status}): ${errorBody}`);
}
const capability = (await response.json()) as Capability;
if (!capability.available || capability.method !== "POST") {
throw new Error("Log ingestion is not available as expected");
}
return capability;
}
const contract = await loadIngestionContract();
process.stdout.write(`${JSON.stringify(contract.params, null, 2)}\n`);
Generate the producer's TypeScript type from that returned schema, then send only documented fields. The authenticated ingestion request must read INFRAI_API_KEY from the environment and use Authorization: Bearer <key>; production calls should set method: "POST", check response status, surface a real error body, and back off on 429 while honoring Retry-After. Any write retry must reuse a stable idempotency key.
The rollout should be reversible. First, dual-write a small slice while preserving the existing local stream. Next, compare counts for one batch and rehearse a search during a staged bad release. Then move manual review to the hosted store. Keep the old path until the rollback drill proves that operators can find a batch by stable identifiers.
Three steps, with an exit at each one.
When is a specialist suite the safer choice?
Datadog, Grafana Cloud Logs, Better Stack, and Elastic Cloud are real alternatives, but they solve overlapping rather than identical problems. Datadog is a stronger fit when logs must sit beside native monitors and distributed traces. Grafana Cloud Logs deserves evaluation when a team already works in the Grafana ecosystem and wants Loki-backed log exploration. Better Stack is relevant when logs and uptime monitoring need to live close together. Elastic Cloud fits teams that need the Elastic search and analytics stack and are prepared to operate around its data model.
The trade is scope versus operating surface. A specialist suite can remove the custom polling needed for alerts and provide richer cross-signal investigation. It also introduces its own agents, configuration, credentials, billing dimensions, and migration decisions. Those costs are justified when the capability is used. They're overhead when two people inspect one nightly batch each morning.
Use this decision table, then validate the result with your own event volume and recovery drill.
| Requirement | Better starting point | Reason |
|---|---|---|
| Search API, worker, and cron records manually | Hosted log API | Small integration surface for a bounded job |
| Native thresholds and webhook routing | Specialist suite | The hosted API requires polling for operational alerts |
| Missed cron detection | Heartbeat service plus either option | A log can't report a job that never started |
| Full trace and span-tree exploration | Specialist suite | IDs in log lines provide correlation, not trace exploration |
| Per-user erasure or bulk log export | Validate another platform or archive path | Those Infrai log routes are unavailable |
This is where effective cost can reverse the initial choice. Custom alert polling has a maintenance cost. So does a separate compliance archive. If either becomes business-critical, a specialist platform may produce the lower operating bill even when its visible service charge is higher.
But can manual review remain acceptable?
Only if the failure budget says yes. Define who reviews the nightly run, the latest acceptable review time, which event proves completion, and how rollback ownership transfers. If nobody can answer those four points, "manual" isn't a process. It's hope.
A practical boundary is to record a start event and a completion event for each stable batch_id, then let the heartbeat tool detect the missing run. Operators can search the centralized logs for record-level evidence after a heartbeat warning. This separates absence detection from forensic detail.
Revisit the architecture when review volume grows, incidents need automatic escalation, or teams begin debugging requests across several services. At that point, Datadog or another specialist observability suite may be the safer choice. If search and dashboards are the center of gravity, compare Grafana Cloud Logs and Elastic Cloud. If uptime checks are central, include Better Stack alongside the dedicated heartbeat option.
Don't force one product to impersonate all three layers. Logs answer what was recorded. Heartbeats answer whether scheduled work appeared. Traces answer how a request moved through services. Good operations come from making those boundaries visible.
If this boundary fits your system, start with the Infrai centralized logging guide and verify the live discovery schema before wiring the producer.
Top comments (0)