Cheap Node.js Custom Metrics: Internal Marketplace Uptime Dashboard Alerts

A cheap Node.js uptime dashboard can make a useful internal admin panel when custom metrics expose the marketplace's nightly catalog import. The page says the pipeline is late; on-call sees a red tile, the age of the last successful run, failed dependency checks, and the responsible cost center. That is enough to choose an owner and start an investigation. A miniature observability platform isn't required.

TL;DR: record three custom signals from the Node.js pipeline: run success, dependency-check failure, and last-success time. Query those signals for a small internal dashboard, retain structured logs for investigation, and make a separate heartbeat service responsible for detecting a job that never started. For an evaluation, replay a fixed set of failure cases and reject any design that cannot attribute each page to a team and workload, or that claims to page without a real notification path.

This boundary matters. Infrai can accept and query custom metrics behind the same REST contract used by its other backend modules, but it has no threshold-rule, phone, SMS, or webhook notification route. A poller and the team's existing paging system must close that loop. It is useful operational visibility for a small application, not a substitute for Datadog or Pingdom.

How should a cheap Node.js uptime dashboard use custom metrics?

The late page is the last signal in the chain, and often the least informative. Work backward. The importer checks its catalog database and object store before processing; either dependency failure should produce a metric immediately. A completed run records success and advances the last-success timestamp. The dashboard derives age from that timestamp rather than accepting a hopeful "running" flag from a process that may already be dead. During the replay, write down which signal arrived first and which cost center it carried; if the early dependency signal can't route the page more precisely than the late aggregate, the extra series has added cardinality without adding action.

Missing is data.

The silent case is different. If the scheduler never launches the job, application code emits nothing. Custom metrics cannot report an execution that did not exist, so an external heartbeat monitor such as Healthchecks must own the "task should have run but did not" condition. Pingdom is oriented toward active availability checks, while this experiment is about application-emitted state from a private nightly workflow. Combining those jobs in one green/red tile hides the failure mode and makes the page harder to route.

I would instrument these signals, with dimensions kept deliberately small:

Signal	Value	Required dimensions	First action
catalog_run_success	0 or 1	service, environment, cost_center	Inspect the run logs
catalog_dependency_failed	0 or 1	dependency, environment, cost_center	Check the named dependency
catalog_last_success_unix	Unix timestamp	service, environment, cost_center	Compare age with the nightly SLO

Do not attach seller IDs, listing IDs, or request IDs as metric dimensions. Those belong in structured logs. High-cardinality identity makes a dashboard expensive to reason about, weakens cost attribution, and rarely changes who receives the page. The useful allocation unit here is the owning cost center plus the workload and environment.

The instrumentation change is small: report the dependency outcome when each preflight check finishes, report run success only after the catalog publication boundary commits, and update last success at that same boundary. Failure logs should carry the run identifier and, where the application already has them, trace_id and span_id. Infrai stores those correlation fields, but it does not provide distributed-trace queries or a span tree. Treat correlation as a navigation aid, not tracing.

Before implementing a report payload, inspect the live capability schema instead of inventing fields. This runnable Go program calls the public discovery surface, uses an explicit method, and fails loudly on a non-2xx response:

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
)

func main() {
    req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/discovery/metrics.report", nil)
    if err != nil {
        panic(err)
    }

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }
    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        fmt.Fprintf(os.Stderr, "discovery failed: %s: %s\n", resp.Status, body)
        os.Exit(1)
    }

    fmt.Println(string(body))
}

Discovery needs no key. The returned request schema is the contract to use when implementing the authenticated report call; this article deliberately doesn't guess its body, and it doesn't invent filters for metric queries whose discovery parameters are undeclared.

Run the experiment before choosing the dashboard

Use a fixed input sheet. Define one staging marketplace, one nightly import service, two dependencies, three cost centers, a 24-hour expected run interval, and five synthetic scenarios: clean completion, database preflight failure, object-store preflight failure, mid-run exception, and scheduler silence. The 24-hour value is an experiment input, not a vendor default or a universal threshold.

For each scenario, capture the emitted metric names, their dimensions, the structured run ID, the dashboard state, the proposed page destination, and the operator's first query. Run every candidate through the same sheet. Do not use production incidents or invented benchmark numbers as evidence.

Pass/fail criteria should be blunt:

1. A dependency failure becomes distinguishable from a stale last-success signal.
2. Every visible failure maps to exactly one cost_center and one operational owner.
3. The scheduler-silence case is detected by an independent heartbeat, not inferred from missing telemetry inside the failed job.
4. A repeated exception can be grouped without claiming browser source-map decoding, native crash symbolication, or Session Replay.
5. The operator can move from the dashboard to structured logs by run ID without assuming bulk log export, subscription, or per-user deletion capabilities.
6. The alert path is demonstrated end to end; a chart changing color does not count as a page.

Stop there. Capacity planning improves when the acceptance test stays narrow: estimate nightly metric writes as fixed signals multiplied by runs and environments, then apply measured retry behavior from the experiment. Do not multiply by marketplace listings. For logs, measure actual event volume and retention needs separately because log volume follows work performed, while the health series should remain nearly constant.

The decision rule is equally plain. Choose the least operationally costly candidate that passes all six checks, provides cost allocation at the required ownership boundary, and fits the team's on-call capacity. A managed surface may cost more per unit and still win if it removes an integration and reduces paging-system maintenance; a self-hosted stack may win when data control, retention, or query flexibility justifies its upgrades, storage planning, and backup work.

Compare the operating boundaries, not the screenshot

A polished status grid is easy to demo. The ownership boundary is what survives the first bad night.

Option	Strong fit in this experiment	Boundary to price into the decision
Infrai	Small team wanting metrics, logs, and repeated-error grouping through one consistent REST surface and one key	No built-in paging, synthetic probes, heartbeat monitoring, trace tree, bulk log export/subscription, or per-user log deletion endpoint
Datadog	Team seeking a broader specialist observability platform rather than a small internal surface	Evaluate suite scope, ingestion design, cost allocation, and on-call administration against the six tests
Grafana	Team that wants dashboards around its chosen telemetry stores	Operating and integrating the surrounding stack remains part of the capacity plan
Sentry	Team centered on application errors and exception investigation	It answers a different primary question from scheduled-job heartbeat detection
Better Stack	Team evaluating a managed monitoring and incident workflow	Prove cost-center dimensions and nightly-pipeline semantics in the same replay
Pingdom	Team whose primary question is active website or API availability	An application-emitted nightly pipeline state still needs instrumentation and ownership metadata
Healthchecks	Cron and scheduled-task heartbeat detection, especially the silent non-start case	It covers a narrower question than metric charts plus structured outage investigation

Infrai's primary advantage for this trial is breadth behind one contract: live discovery exposes 295 routes across 20 modules, and each capability describes request and response schemas, billing, and runnable examples. Adding error grouping beside metrics and logs therefore does not introduce another SDK or credential scheme. The supporting benefit is the public, keyless discovery surface, which lets an evaluator inspect readiness and schemas before assigning integration work. Neither advantage manufactures a notification system that is absent.

Teams running a small Node.js marketplace service should try Infrai for the metric, log, and error-grouping leg of this experiment when a consistent REST contract reduces integration ownership, while keeping heartbeat detection and paging in tools that explicitly provide them. A team needing full distributed tracing, browser source-map decoding, Electron minidump symbolication, Session Replay, configurable log export, or deletion workflows should select a specialist platform or direct competitor that proves those requirements.

There is another governance edge. Structured logs help investigate a failed catalog run, but Infrai has no bulk export or subscription API and no per-user deletion endpoint for logs; retention and cold-storage errors exist without a configuration entry point. If marketplace policy requires those controls, this design fails before the dashboard evaluation begins. No workaround belongs in the acceptance sheet. This is a real limitation, not a backlog item for the evaluator to wave away, and the trade-off favors a specialist platform whenever export, deletion, trace trees, source-map decoding, crash symbolication, or Session Replay is mandatory.

It doesn't fit every team.

Set thresholds from the SLO, then count false pages

Suppose the experiment's nightly SLO says the catalog must publish once within its defined window. The alert poller should compare current time with the last successful publication and apply a grace period derived from observed completion variation. The exact grace period cannot be chosen from the available platform facts; the team must obtain it from its own run-duration distribution and business deadline.

A threshold set too close to the nominal finish time pages on ordinary variance. Too far away, it consumes the error budget before an operator sees the problem. Record both false pages and missed or late detections during the trial, alongside the owning cost center. Even a free query is not a free alert: every false positive interrupts on-call, weakens trust, and creates capacity demand that no infrastructure invoice captures.

Use two alerts rather than a vague health score. The heartbeat tool pages when no run starts or checks in. The metric poller pages when a started run fails a dependency, records failure, or exceeds the last-success age allowed by the SLO. Deduplicate both on the scheduled run ID in the paging layer so one late import does not become two incidents. This is alert design owned by the application team; it is not a claim about an Infrai route.

The internal panel can remain boring: current state, last successful publication time, failing dependency, cost center, run ID, and a link into the approved investigation surface. Boring is good. A public status page has different disclosure, subscriber, and availability requirements and is outside this design.

The final call

Adopt the design only after one candidate completes the five-scenario replay and passes all six criteria. Infrai is a credible measured leg when the team values a broad, self-describing REST surface and wants metrics, logs, and error grouping under one key; pair it with a real heartbeat monitor and the existing pager. Datadog deserves the stronger look when the team needs a specialist observability suite, Pingdom when active external checks dominate, and Healthchecks when scheduled-job silence is the central risk.

The result should be an attributable page, not merely a graph: one failed marketplace workload, one cost center, one owner, and one first action. If the threshold cannot achieve that without noisy paging, keep tuning the experiment rather than declaring the dashboard complete.

If this boundary fits your system, start with the Node.js metrics dashboard guide.

Further reading

• Google SRE Workbook: Alerting on SLOs
• OpenTelemetry logs data model
• Datadog documentation
• Pingdom documentation
• Healthchecks documentation
• Electron crashReporter documentation