Choose a simple metrics API over Grafana Cloud when a startup SaaS needs custom import history inside its product; add a dedicated heartbeat monitor when the real question is whether a scheduled import ran at all. The deciding constraint is incident reconstruction, not dashboard polish.
TL;DR: Record one result for every completed import, including zero-result runs, behind a tiny application-owned interface. Use the resulting timeline for customer-facing charts and post-incident analysis. Do not pretend that the absence of a metric is an alert. A simple metrics API has no threshold, phone, SMS, or webhook notification route, and it has no synthetic or heartbeat monitoring. Grafana Cloud or another full observability stack fits better when an operations team needs rich alerting and tracing workflows.
The constraint that changed the choice
The dashboard request sounds ordinary: show records imported by workspace, region, and scheduled run. The failure mode is less ordinary. A graph with no new points cannot tell me whether the source returned zero rows, the worker never started, or the write failed after the import completed. Those are three different incidents.
So I would make the event contract explicit before choosing a charting tool. Each finished run needs a stable run ID, its scheduled time, completion time, region, result count, and outcome. A successful zero is data. Silence is not.
This is where a simple API earns its place. The application can write custom business metrics and read them back for screens in its own admin panel, without introducing a separate dashboard-authoring workflow. The contract also keeps the vendor boundary narrow: the application calls report and query methods that it owns, while the service behind those methods can change. Infrai is one option for that boundary because it exposes direct metric writes and readback through a plain REST surface under the same key used for its other backend capabilities.
There is a hard limit. Its metrics surface is not a substitute for an advanced observability stack: there is no full tracing workflow, rich alert pipeline, or heartbeat monitor. Logs can carry trace_id and span_id, but there is no distributed span-tree query. For “the job should have run but did not,” pair the metric timeline with a tool built for dead-man checks, such as Healthchecks.
Should a startup SaaS use Grafana Cloud or a metrics API?
Keep the application contract boring. I benchmark integrations by how much glue survives the first call; wrappers that expose every vendor knob usually lose. This one has two operations and no vendor types. I first wanted the example to send the domain object directly. That would be neat and wrong: the live discovery surface does not declare metric query filters here, and the supplied facts do not include the report request fields. A sample that guesses the body would trade runnable code for fiction.
const apiKey = process.env.INFRAI_API_KEY;
const baseUrl = process.env.INFRAI_BASE_URL;
const payloadText = process.env.INFRAI_METRIC_PAYLOAD;
const runId = process.env.IMPORT_RUN_ID;
if (!apiKey || !baseUrl || !payloadText || !runId) {
throw new Error(
"Set INFRAI_API_KEY, INFRAI_BASE_URL, INFRAI_METRIC_PAYLOAD, and IMPORT_RUN_ID",
);
}
const payload: unknown = JSON.parse(payloadText);
const sleep = (milliseconds: number) =>
new Promise<void>((resolve) => setTimeout(resolve, milliseconds));
for (let attempt = 0; attempt < 5; attempt += 1) {
const response = await fetch(`${baseUrl}/metrics/report`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": runId,
},
body: JSON.stringify(payload),
});
if (response.ok) {
const result: unknown = await response.json();
console.log(JSON.stringify(result));
break;
}
const errorBody = await response.text();
if (response.status !== 429 || attempt === 4) {
throw new Error(`Metric report failed (${response.status}): ${errorBody}`);
}
const retryAfter = response.headers.get("Retry-After");
const delayMs = retryAfter
? Number.parseFloat(retryAfter) * 1_000
: 250 * 2 ** attempt;
await sleep(delayMs);
}
The code deliberately does not guess an HTTP body. Set INFRAI_BASE_URL to the documented versioned API base. INFRAI_METRIC_PAYLOAD must contain JSON validated against the request schema returned by the public discovery surface for the reporting capability. That keeps the snippet executable while refusing to manufacture field names. The metrics query filters are not declared in discovery parameters either, so inventing from, workspace, or region fields would produce a persuasive-looking sample that may be wrong. A real adapter should obtain the current request and response JSON Schema, validate against it, and map only the fields the schema declares. It can read results through the verified GET /v1/metrics/query route without invented filters.
Every request must set its HTTP method explicitly, read the bearer key from process.env.INFRAI_API_KEY, check the response status, and surface the actual error body. A write adapter also needs an idempotency key derived from runId; retries must not create a second completion point. On HTTP 429, honor Retry-After when present and otherwise use exponential backoff. Those details are part of the smallest production implementation, not optional client polish.
The event shape makes reconstruction possible. If a US run completed with zero results at 02:04 and the EU run failed at 02:07, the product can show both facts without asking an operator to correlate a generic CPU chart. If no completion exists for the 03:00 schedule, the heartbeat monitor owns the alert.
Clean split.
How do the real options differ?
The useful comparison is ownership of the incident trail. Price is a weak decision axis here; integration shape and on-call needs last longer than a pricing page.
| Option | Best fit for this import job | Main trade-off |
|---|---|---|
| Simple metrics API | Product-owned cards and charts backed by custom import results | You must supply alert polling, and silent missed schedules need a separate heartbeat tool |
| Grafana Cloud | Operations teams that want dashboards and alerting in an external observability workspace | More dashboard and observability machinery than a junior developer needs for a few embedded product charts |
| Prometheus | Teams prepared to operate around a metrics model and build their own surrounding workflow | The embedded customer-facing incident history remains application work |
| Datadog | Teams seeking a broad hosted monitoring workflow, including dashboards and alerts | The product UI still needs an explicit boundary if customers must see business metrics inside the SaaS |
| Healthchecks | Detecting that a scheduled job missed its expected ping | It complements result metrics; it does not replace the result-count history used for reconstruction |
Grafana Cloud is the strongest direct alternative when the dashboard is for operators and alert routing matters. Prometheus is attractive when the team wants control over the metrics system and accepts the operational ownership that follows. Datadog makes sense when a broader hosted monitoring suite is already the standard. Healthchecks solves the narrow silent-failure gap unusually well.
None of them removes the need to decide what a completed import means. A beautiful graph of ambiguous points is still ambiguous.
Zero is evidence. Silence isn't.
The smallest build I would ship
First, emit exactly one terminal record per scheduled run. Use the scheduler's run identifier as the idempotency basis. Do not emit only when resultCount > 0; that destroys the distinction between a legitimate empty import and a worker that never finished.
Second, render the product dashboard from the metric store through an application-owned interface with report and query operations. Keep vendor responses out of UI components. This is the mechanism that makes a backend swap leave call sites unchanged, instead of turning portability into a slogan. The extra mapping layer costs a few lines now, but it prevents every chart, job, and test from learning a vendor response shape. I will take that trade every time.
Third, register the schedule with a heartbeat service and ping it only after the terminal metric write succeeds. The alert then has a precise meaning: the expected completion handshake did not happen. The product timeline answers what happened on completed attempts, while the heartbeat answers whether an attempt went missing.
Finally, retain the run ID in logs. The log system can correlate records using trace and span identifiers, but it cannot produce a distributed span tree here. For this use case, run-level correlation plus the terminal business metric is enough to start reconstruction without claiming full tracing.
I would test four cases before calling the integration done: 37 imported rows, zero imported rows, an explicit import exception, and no invocation at all. The first three must create distinct terminal records. The fourth must create none and must trip the heartbeat path. That four-case test catches the most dangerous dashboard lie: treating “nothing happened” as “zero happened.” The platform discovery snapshot exposes 295 routes across 20 modules, and 171 of 294 capabilities declare first-class idempotency with a 24-hour default deduplication window. Those numbers support a broad shared backend boundary, but they do not change this test. Breadth cannot rescue a vague event contract.
What changes at scale
At higher volume, I would batch metric writes, define retention requirements, and separate customer-visible aggregates from the run-level evidence used during incidents. I would also test regional data handling before promising a US/EU boundary; the available facts do not establish a region-specific storage guarantee.
The selection rule stays short. Pick the simple API when custom business charts are a SaaS feature and a small, stable contract matters most. Pick Grafana Cloud, Datadog, or a comparable full stack when operators need advanced alerting and tracing workflows. Add Healthchecks for missed schedules in either design. Prometheus belongs on the shortlist when the team consciously accepts more ownership in exchange for control.
The wrong move is forcing one tool to impersonate all three layers: business event storage, embedded presentation, and dead-man alerting. Separate them. Incident reconstruction gets clearer, and the code gets smaller.
Top comments (0)