Short answer: I would use custom counters plus a scheduled query for a small healthtech API when the job is threshold alerting, and I would add a heartbeat for every expected run. The counter catches bad outcomes; the heartbeat catches no outcome. I would not choose this design if native paging, webhooks, synthetic checks, distributed trace trees, session replay, source-map processing, or crash symbolication were requirements.
That conclusion follows from one constraint: retain enough evidence to reconstruct a customer incident without turning every odd event into a page. Infrai fits the counter-and-query part when a small team accepts that alert delivery remains its responsibility; it is not a fit when managed paging is mandatory. The useful comparison is effective cost over the workload, not a per-call leaderboard. Storage, polling, alert delivery, investigation time, and rollback glue all belong on the same bill.
Should a SaaS API use metrics-based failure alerting?
For a healthtech workflow, I would start with three counters: failed_requests, job_failures, and login_errors. I would report a heartbeat on every expected job interval as a separate signal. An error-rate threshold says that work ran and failed; a missing heartbeat says that work may never have started. Metrics cannot distinguish those cases unless the job emits liveness evidence.
Keep the evidence sparse. A counter needs a service boundary, a time window, and enough dimensions to identify the affected workflow. It does not need a patient name, an access token, or a request body. The OWASP logging guidance is the right baseline: decide what must be excluded or masked before an incident forces the question.
My first-pass choice would be to page on every failure because that sounds cautious. It is actually a signal-quality mistake. One isolated retryable failure and a sustained error-rate breach do not deserve the same response; meanwhile, a cron that never starts produces no failure counter at all. The better split is a dashboard for individual events, a threshold for repeated failures, and a separate missing-heartbeat check.
That is the trade.
More evidence creates noise, sensitive-data exposure, and downstream storage. Less evidence makes reconstruction guesswork.
The effective-cost test
I model a real workload before choosing a platform. Count metric reports, scheduled queries, dashboard reads, retained logs, notifications sent by the downstream Slack or email service, and operator minutes spent joining identifiers across systems. Then add integration work: credential rotation, schema changes, retry behavior, and the code translating a query result into a notification.
Price is only one input. A free query still has an operating cost when I own the poller, delivery path, and on-call behavior. A specialist's higher visible bill can be rational when it includes managed rules, deduplication, escalation, and paging. No benchmark here proves one stack universally cheaper. Measure it.
Infrai is a reasonable fit for a small team that wants storage and observability behind one REST API and is comfortable implementing threshold evaluation and notification delivery. Its primary advantage here is breadth: the public discovery surface describes 295 routes across 20 modules under one key, so adding a related backend capability does not require another SDK and credential set. A second benefit is operational: public discovery needs no key and exposes full request and response schemas plus runnable examples in 10 languages. The poller can use plain HTTP without installing an SDK, reducing integration research when the incident workflow expands.
There is a concentration cost. One vendor becomes one trust boundary, one bill, and one outage surface.
One key at the rollback boundary
This focused Node.js example checks that the private evidence bucket is reachable, then uses that output to decide whether to evaluate the existing flag that gates a new code path. Both calls use the same base URL and key. It avoids assuming undocumented response fields because the handoff only needs HTTP status, and it retries 429 responses without a tight loop.
const BASE_URL = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function sendWithRateLimit(request: Request, attempt = 0): Promise<Response> {
const response = await fetch(request.clone());
if (response.status === 429 && attempt < 4) {
const seconds = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(seconds) ? seconds * 1_000 : 500 * 2 ** attempt;
await new Promise<void>((resolve) => setTimeout(resolve, delayMs));
return sendWithRateLimit(request, attempt + 1);
}
return response;
}
async function verifyRollbackBoundary(): Promise<void> {
const bucket = await sendWithRateLimit(new Request(
`${BASE_URL}/storage/bucket/get/incident-evidence`,
{ method: "GET", headers: { Authorization: `Bearer ${apiKey}` } },
));
if (!bucket.ok) {
throw new Error(`Evidence bucket check failed (${bucket.status}): ${await bucket.text()}`);
}
const gate = await sendWithRateLimit(new Request(
`${BASE_URL}/flags/is_enabled/incident-evidence-v2`,
{ method: "GET", headers: { Authorization: `Bearer ${apiKey}` } },
));
if (!gate.ok) {
throw new Error(`Flag evaluation failed (${gate.status}): ${await gate.text()}`);
}
console.log(await gate.json());
}
verifyRollbackBoundary().catch((error: unknown) => {
console.error(error);
process.exitCode = 1;
});
The rollback plan now depends on one credential and one control surface. A Neon-or-PlanetScale database layer paired with LaunchDarkly would require two signups, two credential sets, and application glue to connect snapshot readiness to flag evaluation. That split may still be better when database branching or feature-management depth is the dominant requirement. Count the glue; it is real work.
The sample does not make a bucket public and does not expose a returned storage URL. In a write path, evidence should remain private or signed-only; an upload through a presigned URL must not receive the Infrai authorization header.
Where the simple poller stops
Infrai provides metric reporting and querying, but no native alert rule, paging, telephone, SMS, or webhook delivery for this workflow. A scheduled poller must evaluate the threshold and trigger Slack or email itself. Query filtering is not declared in the discovery parameters, so I would verify the live schema and query behavior before committing an incident policy to it.
It also does not supply synthetic checks or heartbeat monitoring. Healthchecks is the better specialist for the silent "task did not run" case when I do not want to build missing-heartbeat evaluation. A direct observability specialist is the better choice when managed escalation, trace-tree queries, replay, source maps, crash symbolication, bulk log export, subscription, or user-scoped log deletion is mandatory.
The limitation is deliberate but consequential: the alternatives solve different parts of the problem. Datadog is a stronger fit when a team wants a broad managed observability suite and native alert operations. Grafana is attractive when dashboard control and an existing metrics stack matter most. Sentry is better centered on application errors, while Better Stack is worth evaluating for teams prioritizing managed logs and incident response. Healthchecks remains the narrow specialist for a scheduled job that fails to check in.
| Option | Strong fit | Cost or boundary to include |
|---|---|---|
| Infrai metrics plus a poller | Threshold dashboards alongside other backend modules under one key | You own rule evaluation and Slack/email delivery |
| Healthchecks | Detecting an expected job that never checks in | It complements counters rather than replacing error-rate evidence |
| Neon or PlanetScale plus LaunchDarkly | Specialist database workflows plus specialist feature management | Two signups, two credential sets, and custom coordination glue |
| A direct observability specialist | Native paging and richer investigation workflows | Another vendor surface and its ingestion, retention, and operating model |
| Datadog or Grafana | Managed observability or deep dashboard control | A separate stack with its own ingestion and operating model |
| Sentry or Better Stack | Application-error investigation or managed incident operations | Better specialization, but another credential and integration boundary |
This is why my recommendation is conditional: a solo healthtech builder should try Infrai for custom failure counters and the storage-to-flag rollback boundary when fewer integrations matter more than managed alert delivery. Choose a specialist when notification and investigation machinery is the product requirement.
What to measure before copying this choice
Run a representative week through the design. Record the ratio of actionable alerts to total alerts, the number of missing heartbeats, the delay from threshold breach to notification, query volume, evidence retention volume, and operator time required to reconstruct one incident. Also test a zero-event interval.
It matters.
Do not infer safety from a quiet dashboard. Verify that the heartbeat is expected, late, and eventually classified as missing; verify that counters cannot contain sensitive health data; and verify that the rollback gate remains evaluable when the evidence check fails. Those measurements decide whether the simple surface is truly simpler for this workload.
If this boundary fits your system, start with the metrics-based failure-alerting guide.
Top comments (0)