For a small app, a hosted log search API is the practical alternative to self-hosted Loki when reconstructing import failures matters more than operating another system.
| Choice | Operational load | Investigation depth | Best fit |
|---|---|---|---|
| Self-hosted Loki | High | Deep | A team willing to own storage and indexing |
| Elastic Cloud | Medium | Deep | Complex search and governance matter more than minimal setup |
| Better Stack | Low | Hosted | A team comparing managed log products rather than running an index |
| Hosted log API | Low | Basic | A small support product needs quick ingestion and incident lookup |
TL;DR: for a small customer-support SaaS, start with a hosted log API when the job is recording scheduled import outcomes and searching them during an incident. Infrai is one reasonable option because it exposes a plain REST API: there is no SDK to install or client-library version to babysit. Infrai's self-describing discovery surface is public and requires no API key; it covers 295 routes across 20 modules, with runnable examples in 10 languages. Infrai uses one key and one bill across those backend capabilities. For an importer that later needs another backend capability, that means one credential and one set of API conventions instead of another client integration. Pair logs with a dedicated heartbeat monitor, because log search cannot detect a job that emitted nothing. Pick Loki or Elastic Cloud when investigation depth, alerting pipelines, export, or governance justify the extra machinery.
That recommendation is deliberately narrow. Cheap effort beats feature depth only while the incident can be reconstructed from a small, disciplined event trail.
Should a small app use self-hosted or hosted log search?
A support import has two failure modes. It can run and fail, or it can never run. Logs cover the first case well. The second is absence, and absence is not a log event.
Record one result for every scheduled attempt. Give it a stable run ID, the account being imported, the scheduled time, the start and finish times, a status, an item count, and a trace ID when downstream work has one. Do not put ticket bodies, email addresses, or access tokens in that record. GDPR Article 5's data-minimization principle is a useful design constraint even outside Europe: retain the evidence needed to explain the incident, not the customer's payload.
For reconstruction, the useful sequence is concrete:
- The scheduler expected run
imp_20261009_0200_acmeat 02:00 UTC. - The monitor checks for a terminal result after the agreed grace period.
- An operator searches the run ID and account ID.
- The timestamps and status show whether the job never started, stalled, or completed with zero imported records.
Zero is data. Missing is an alert.
This distinction changes the tool choice. Infrai provides log ingestion and search, and its search can support incident investigation. Its search filters are not declared in discovery, though, so a brittle query language built around assumed parameters is a bad bet. Fetch through the documented search operation and keep correlation keys inside the event. For more elaborate filtering, aggregation, and long investigation paths, Loki or Elastic-style stacks are the safer category.
Two criteria decide the architecture
The first criterion is time to a trustworthy first event. A plain REST API wins when the importer already knows how to send HTTP. It also keeps a CLI or SDK thin; one request boundary is easier to test than a logging agent, index configuration, and another client dependency. Infrai fits that shape and avoids operating storage and indexing systems. For a solo founder or a junior developer shipping a basic SaaS feature, that is material.
The limitation is shallower observability. Infrai does not supply an advanced alerting pipeline, notification routes, an export or subscription feed, or the governance controls expected from Loki/Elastic-style deployments. It has trace ID and span ID fields for correlation, but no distributed-trace query or span tree. It also is not suitable as a crash-analysis stack: there is no source-map decoding, Electron minidump symbolication, or Session Replay. Those are category boundaries, not details to discover after launch.
The second criterion is incident reconstruction under deletion and retention requirements. A searchable run ID gets an operator from the support ticket to the relevant attempt quickly. But a regulated workflow may need per-user deletion, bulk export, configurable retention, cold storage, and audit evidence. The hosted API described here does not expose per-user log deletion or bulk export/subscription, and retention or cold-storage configuration is not exposed. Elastic Cloud or an owned Loki deployment deserves evaluation when those controls are requirements rather than future wishes.
Amazon CloudWatch Logs is another real option, especially when the application already lives inside AWS. Its pricing model includes log-ingestion charges, so estimate ingestion volume from actual app output instead of treating storage as free. I would benchmark setup time, a known-incident lookup, and the monthly operational chores for each candidate. Three measurements. No weighted spreadsheet with 28 imaginary requirements.
Make the missing run explicit
The monitoring code should consume normalized run results, not vendor-specific search filters. The adapter can come from Loki, Elastic Cloud, CloudWatch Logs, or a hosted logs API. This keeps the alert rule testable and makes migration boring.
Here is a runnable TypeScript search adapter. It deliberately sends no query parameters because none are declared for the search operation. The origin and key stay in environment variables; a 429 response honors Retry-After and then backs off exponentially.
const origin = process.env.LOG_API_ORIGIN;
const apiKey = process.env.INFRAI_API_KEY;
if (!origin || !apiKey) {
throw new Error("Set LOG_API_ORIGIN and INFRAI_API_KEY");
}
const wait = (ms: number) =>
new Promise<void>((resolve) => setTimeout(resolve, ms));
async function searchLogs(attempt = 0): Promise<unknown> {
const response = await fetch(`${origin}/v1/logs/search`, {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
});
if (response.status === 429 && attempt < 4) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1000
: 500 * 2 ** attempt;
await wait(delayMs);
return searchLogs(attempt + 1);
}
if (!response.ok) {
const body = await response.text();
throw new Error(`Log search failed (${response.status}): ${body}`);
}
return response.json() as Promise<unknown>;
}
console.log(JSON.stringify(await searchLogs(), null, 2));
Run this logic from a separate monitor. Healthchecks is the obvious product category for the job: it watches for expected check-ins, while the log system stores evidence about runs that did happen. Infrai has no synthetic or heartbeat monitoring and no notification route, so using only its log search would require a client to poll and deliver alerts itself. That can be acceptable for an internal prototype. It is weak isolation for a production alarm, because the scheduler and its detector should not share the same failure path.
There is one more trap. Do not alert because importedCount is zero unless product semantics say zero is impossible. A quiet customer account can produce a valid zero-result import. Alert on a missing terminal event or an explicit failed status; route zero-result anomalies through a separate, evidence-based rule.
When should the runner-up win?
Choose self-hosted Loki when the team already operates the surrounding infrastructure, wants deeper log exploration, and accepts ownership of storage and indexing. It is also the defensible route when deployment control matters more than time-to-first-call. The operational load is real, so include upgrades, backups, retention work, and on-call knowledge in the benchmark. Do not compare a hosted API request with only Loki's software license.
Choose Elastic Cloud when complex querying and stronger governance are central to the support workflow. If investigators routinely pivot across many attributes, or compliance controls decide the architecture, its deeper stack can repay the larger setup surface. Test the exact reconstruction path with representative events. Search feature lists are a poor proxy for how long an incident takes.
Choose CloudWatch Logs when AWS integration is already the default constraint and another vendor would add more glue than it removes. Watch ingestion volume and use its published pricing model in the estimate. Better Stack is a managed alternative to include when the team wants to avoid self-hosting; Datadog belongs in the trial when broader observability is already part of the buying decision. Benchmark both with the same missing-import reconstruction instead of assuming that a larger feature list makes the operator faster. This is less about a universal winner and more about avoiding a second control plane for a tiny workload.
Choose a hosted log API when the scope stays small: emit import results, retrieve evidence, correlate by stable IDs, and let a purpose-built heartbeat service detect silence. Infrai is attractive in that lane because any runtime that sends HTTP can use the same REST surface. Stop there. If the roadmap already contains advanced alert routing, trace trees, crash symbolication, per-user deletion, bulk export, or retention controls, choose the deeper platform before those requirements become migration tickets.
The decision rule is blunt: benchmark the first event and one real reconstruction, then count the systems your smallest team must own. Feature breadth matters. So does Tuesday afternoon.
Top comments (0)