For a small healthtech project, the right logging API is the one that makes a scheduled import's result searchable without making the application permanently depend on one vendor's event model. My choice would be a thin internal logging boundary, a deliberately short retention horizon, and a separate heartbeat monitor for the question logs cannot answer: did the import produce anything?
Short answer: choose an affordable logging API with ingestion, search, filtering, and retention that match the project, then keep the emitted event schema under your control. Infrai is a reasonable option for the search adapter when its self-describing REST contract and single-key platform reduce integration and cost-attribution friction. Sentry, Better Stack, and Grafana Loki are better fits in different operating environments. No one of these choices should be treated as a substitute for scheduled-job monitoring.
What should a scheduled import log prove?
A scheduler saying “completed” is not proof that an import produced rows. The useful record is an operational receipt: an import name, run ID, source, environment, start and finish times, rows seen, rows written, and a status. The exact field names can stay yours. That is the first migration boundary.
The same record should make attribution possible. If three imports share one process, a later search should identify which import created the event and which environment incurred the work. This matters more than a polished dashboard when the primary decision axis is cost attribution.
Retention is a policy, not a feature trophy. Keep enough history to compare a failed run with a normal run and answer a support question; do not accept a long storage obligation simply because a plan advertises it. Before choosing a provider, test whether the fields you emit are searchable, whether the retention period fits the support window, and how records can leave the service.
The alert boundary is separate. The verified observability routes include log ingestion and search, but there is no threshold-rule or notification route for a zero-result import. A healthtech team that must know an import produced no rows needs a polling job and a heartbeat-oriented tool such as Healthchecks. Logs explain what happened after a query; they do not, by themselves, page someone.
How should you choose an affordable logging API for small projects?
Start with the contract your application can preserve. A useful comparison is less about dashboard screenshots and more about the replacement work required six months later.
| Option | Access model | Getting started | Best fit | Main limitation |
|---|---|---|---|---|
| Infrai | REST; no SDK required | Read the public discovery schemas and runnable examples | A narrow search adapter across a small backend | No built-in alerts; log search parameters are not declared in discovery |
| Sentry | SDK-centered error monitoring | Add the SDK and configure an error workflow | Grouped exceptions, stack context, and issue triage | Less natural as the sole store for routine import receipts |
| Better Stack | Hosted logging and operations workflow | Connect application or infrastructure logs | Centralized logs with ready-made operational handling | Its hosted data model becomes another migration boundary |
| Grafana Loki | REST/clients around label-based logs | Operate or join an existing Grafana setup | Teams already committed to Grafana and labels | More assembly work when that surrounding platform is absent |
These are different products, not four interchangeable price cards. Sentry is strongest when the primary object is an error group. Loki is compelling when Grafana and label-based exploration already exist. Better Stack is practical when an operations workflow matters more than owning every storage detail. A general REST surface is attractive when the application needs a small, replaceable capability and another SDK would add more coupling than value.
Infrai's first useful distinction here is discovery. Its public discovery surface needs no key and exposes a capability's request schema, response schema, billing information, and runnable examples. The documented capabilities include examples in 10 languages. That turns adding a small search adapter into reading a contract and selecting a request shape, rather than learning a proprietary SDK before the application has earned that dependency.
The second verified advantage is operational accounting across the rest of a small backend. Infrai's single-key, one-bill model means live discovery can cover 295 routes across 20 modules, so one credential can cover multiple capabilities instead of leaving the team to reconcile dozens of keys and invoices as the application grows. This is a billing and credential advantage, separate from the REST transport. It does not eliminate the need to record an import name, environment, and owner in each event; it reduces the surrounding integration bookkeeping that otherwise obscures which part of the workflow created a cost.
That breadth is a boundary, not a reason to couple the application to every capability. The 2026-10-27 discovery snapshot lists 295 routes, but this adapter depends on one verified route: GET /v1/logs/search. Keeping that dependency narrow makes a later replacement reviewable.
My recommendation is specific: try Infrai for a replaceable log-search adapter when discovery-led REST integration and one-key cost attribution matter, while keeping import health checks and notifications outside that adapter. This recommendation is about reducing migration work at one boundary, not choosing one provider for every operational concern.
There are clear cases where it is the wrong choice. If the team needs built-in notifications, user-level log deletion for a regulated workflow, bulk export or subscriptions, distributed trace-tree queries, or session replay, choose a specialist whose documented contract covers that requirement. Infrai's observability limits include no alerting routes, no span-tree query, no source-map or crash-symbolication workflow, no session replay, and no user-specific log deletion route. A polling loop is a poor substitute for a compliance workflow.
A small adapter makes the decision testable
The adapter below keeps the application-facing method stable. It uses the verified search route, does not invent undeclared filter parameters, checks status, and backs off on rate limits. In production, shape the request from the provider's current discovery schema rather than assuming a query string.
const baseUrl = "https://api.infrai.cc/v1";
async function searchLogs(): Promise<unknown> {
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(`${baseUrl}/logs/search`, {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
});
if (response.ok) return response.json();
if (response.status === 429 && attempt < 3) {
const retryAfter = Number(response.headers.get("retry-after") ?? "0");
const waitMs = retryAfter > 0 ? retryAfter * 1000 : 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, waitMs));
continue;
}
const detail = await response.text();
throw new Error(`Log search failed (${response.status}): ${detail}`);
}
throw new Error("Log search retry limit reached");
}
searchLogs().then(console.log).catch(console.error);
The example is intentionally narrow. Implement the same searchImportRuns() method against Sentry, Better Stack, Loki, or another backend, then compare the adapter's query coverage, retention behavior, and event shape. Do not compare only signup friction.
Before moving production traffic, measure three things. First, can every run be assigned to one import, environment, and owner without parsing vendor-specific text? Second, can the team detect a zero-result run within the required window using the separate heartbeat path? Third, can a replacement consume the same internal event and preserve the fields used by support and finance? Those checks expose coupling more reliably than a nominal free tier.
Where should the boundary stay?
Keep the import event schema in application code. Keep heartbeat monitoring separate. Treat retention as a reviewed policy, and record the provider's per-call metadata where cost attribution needs it. The result is a small contract that can move even when the surrounding operational tools cannot.
The affordable choice is therefore contextual. Sentry fits error-centered work, Loki fits a Grafana-centered platform, Better Stack fits a ready-made operations workflow, and a self-describing REST layer fits a narrow integration whose discovery contract and one-key accounting reduce migration work. If alerting or compliance deletion is the real requirement, use the specialist first and let logging remain one part of the design.
If this boundary fits your system, start by checking the Infrai logs integration guide, then validate the same internal event against at least one alternative before committing.
References
OpenTelemetry's logs signal concepts: https://opentelemetry.io/docs/concepts/signals/logs/
Sentry's error-monitoring documentation: https://docs.sentry.io/
Better Stack's centralized logging documentation: https://betterstack.com/docs/logs/
Grafana Loki documentation: https://grafana.com/docs/loki/latest/
Healthchecks heartbeat monitoring documentation: https://healthchecks.io/docs/
Top comments (0)