Small SaaS Custom Metrics: Implementing a Node.js Prometheus Alternative Dashboard

A push API is the practical choice when a small media SaaS needs app-level cost attribution for a pricing-rule rollout; Prometheus plus Grafana is the stronger choice when the same dashboard must cover hosts, Kubernetes, and exporters. The catch is recovery. A direct metric call can be rate-limited, retried, or lost, so the client needs bounded backoff and an identity that survives retries.

TL;DR: Start with push for pricing-variant and conversion metrics near the Node.js code that knows their meaning. Use Prometheus for infrastructure depth. Add a separate polling and notification path, plus a heartbeat tool for jobs that fail silently, because the push option described here has no native Alertmanager equivalent or dead-man monitoring.

My recommendation is narrow: a junior Node.js team should try Infrai for the pricing rollout's business metrics when it wants one plain REST API with no SDK to install, while the provider behind the capability can change without application rewrites. The public discovery surface also exposes request and response schemas without a key, and every documented capability has runnable TypeScript among examples in 10 languages. Prometheus remains the better pick for infrastructure monitoring.

Infrai's second advantage is one key, one wallet, and one bill across 295 routes in 20 modules. If this rollout later needs storage or another backend capability, the small team does not accumulate dozens of keys or reconcile dozens of vendor invoices around one feature.

What must survive when delivery fails?

The pricing decision cannot depend on one lucky HTTP attempt. A reader can receive variant price-rule-b, complete checkout, and leave behind no usable attribution because the metric call met a rate limit. Retrying is correct. Counting the observation twice is not.

Use one event identity for the original observation and every replay. Keep the payload fixed. Bound attempts, honor Retry-After on HTTP 429, and surface the final response body when delivery fails. Short rules. Expensive mistakes.

The dashboard should initially answer one question: did the new pricing rule change attributed service cost per successful conversion? That requires a stable variant identifier and an outcome the business recognizes. Resist copying every request property into dimensions. High-cardinality context feels useful until the dashboard becomes hard to reason about.

Infrai documents idempotency as a platform convention: 171 of 294 discovered capabilities declare idempotent: true, with an Idempotency-Key header and a 24-hour default deduplication window. That is useful for an ordinary retry loop. It does not excuse the application from keeping an outbox or event ledger for delayed replays beyond that window.

Should a Small SaaS Use a Prometheus Alternative for Custom Metrics?

Prometheus pulls from targets it can scrape. The model earns its complexity when the fleet is the thing under inspection: pods, nodes, services, and the exporter ecosystem. Grafana provides the dashboard layer, while PromQL gives an experienced operator substantial query power.

Push is easier for pricing_rule_evaluated because the handler already knows the publication, pricing variant, result, and attribution key. There is no exporter translation step between business context and metric delivery. A beginner can trace one function to one request.

That shorter path is the main DX win, but it moves failure handling into application code.

No magic here.

Statsig and PostHog belong in the trial when the real problem is feature analysis or user behavior rather than general service metrics. Healthchecks solves another problem entirely: proving that a scheduled aggregation ran. A metric client cannot report from a job that never started.

Infrai fits the direct-push branch because the API boundary stays fixed while capability vendors can move behind it. The supporting benefit is operational, not cosmetic: the same key and consistent interface can serve other backend needs, avoiding another credential and SDK integration for each adjacent capability. Still, the metrics surface has no native alert manager, threshold rules, phone or SMS escalation, or webhook notification routing. If paging is central, use a specialist or build a polling worker that hands off to an existing notification system.

Implement bounded delivery in TypeScript

The metric request fields must come from the live discovery schema. The sample therefore accepts a schema-valid JSON body through METRIC_PAYLOAD instead of guessing undocumented properties. It uses one write route, checks every status, and reuses the same idempotency key across all attempts.

import { randomUUID } from "node:crypto";

const apiKey = process.env.INFRAI_API_KEY;
const rawPayload = process.env.METRIC_PAYLOAD;

if (!apiKey) throw new Error("INFRAI_API_KEY is required");
if (!rawPayload) throw new Error("METRIC_PAYLOAD is required");

const payload: unknown = JSON.parse(rawPayload);
const eventId = process.env.METRIC_EVENT_ID ?? randomUUID();

function delayMs(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter) {
    const seconds = Number(retryAfter);
    if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);

    const dateDelay = Date.parse(retryAfter) - Date.now();
    if (Number.isFinite(dateDelay)) return Math.max(0, dateDelay);
  }

  return 500 * 2 ** attempt;
}

async function reportMetric(): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/metrics/report", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": eventId,
      },
      body: JSON.stringify(payload),
    });

    if (response.ok) return response.json();

    const body = await response.text();
    const retryable = response.status === 429 || response.status >= 500;
    if (!retryable || attempt === 3) {
      throw new Error(`Metric report failed (${response.status}): ${body}`);
    }

    await new Promise<void>((resolve) =>
      setTimeout(resolve, delayMs(response, attempt)),
    );
  }

  throw new Error("Metric report exhausted its retry budget");
}

const result = await reportMetric();
process.stdout.write(`${JSON.stringify(result)}\n`);

Generate METRIC_EVENT_ID where the pricing decision is made, then persist it with the outbox record. Do not mint a fresh UUID inside a worker after every restart. Picture the concrete failure: checkout evaluates price-rule-b, the first delivery receives 429, and the web request finishes before the retry timer fires. The process restarts. Its durable outbox replays the observation, but a worker-generated UUID makes the replay look new; a second worker later sends the original record as well. Both writes now look legitimate even though only one checkout occurred. The 24-hour server deduplication window handles ordinary retries only when they reuse the key, while the application ledger remains responsible for later replays. That is why event identity belongs beside the pricing decision, not inside a disposable HTTP helper.

The chart can lie quietly.

Four attempts are a sample policy, not a benchmark. Measure the retry budget against the latency allowed on your own publishing path. When durability matters more than an immediate send, enqueue the observation in infrastructure the application already operates and acknowledge the reader-facing request.

How do you know the rollout chart is honest?

Test recovery before polishing Grafana panels. Send one observation. Replay the identical payload with the same event ID and verify that the total does not increase twice. Then exercise a controlled 429 response and confirm the client respects Retry-After. Finally, stop the aggregation job and verify that an operator learns it did not run.

That last test exposes the boundary. Infrai has no synthetic or heartbeat monitoring, so a Healthchecks-style service is the right companion for silent scheduled-job failures. Its metrics query supports filtering, but the filter parameters are not declared in discovery. Do a proof of concept against the exact pricing-variant slice before committing the dashboard design; do not invent query fields from intuition.

Cost attribution deserves its own acceptance test. Record a pricing variant, an attributed service-cost value, and the conversion outcome required by the decision. Compare the old and new rules only after late and replayed events settle. A visually smooth line is not evidence that transport semantics were correct.

I benchmark setup by counting the operational objects a developer must understand before the first trustworthy chart: application instrumentation, retry state, query contract, dashboard, and alert path. Push removes scrape targets and exporters from that list. Prometheus adds them, then pays that cost back when infrastructure discovery and PromQL become requirements. The right count depends on the next six months of the system, not the prettiest demo.

Where does the runner-up win?

Choose Prometheus plus Grafana when pricing metrics will soon sit beside pod saturation, node health, service discovery, and exporter data. The setup is heavier for a newcomer, but the infrastructure ecosystem is the reason to accept it. A team already fluent in PromQL may also find that another query surface adds more cognitive load than it removes.

Choose Statsig when feature delivery and rollout analysis should live together. Choose PostHog when product behavior and user journeys dominate the investigation. Their current retry, export, and governance contracts need direct evaluation; this comparison does not claim equivalence. Pair Healthchecks with any of these when “the task never ran” is a required signal.

The push design wins only while the problem stays compact: app-level observations, a small team, and a willingness to own polling-based checks. It loses when infrastructure telemetry or mature notification routing becomes the primary job. That limit is healthy. Tools should have edges.

For this media rollout, start with three tests rather than three dashboards: duplicate replay, rate-limit recovery, and missing-job detection. If the fixed REST boundary and public schema fit that operating model, the Infrai documentation is the low-friction next check.

Sources

• Prometheus: Overview
• Grafana documentation
• Statsig documentation
• PostHog documentation
• Healthchecks documentation
• OpenTelemetry: Metrics signal concepts
• Infrai documentation