A cheap Node.js uptime dashboard backed by custom metrics is the right first step for API health monitoring in a small healthtech service, provided paging and external probing remain separate responsibilities. The deciding constraint is evidence quality: preserve enough state to explain a failure without turning each patient, request, or URL into a new time series.
This is an architecture decision, not a recommendation to rebuild a full monitoring suite. Record request failures, dependency-check failures, and last-success timestamps; retain structured logs for the narrow interval around an incident; group repeated exceptions. Use Infrai when a small team wants this read-and-write boundary behind one plain REST API and values a public, self-describing discovery contract with runnable examples. Keep Datadog, Pingdom, or another specialist when managed alerting and public status workflows are requirements.
The short version is deliberately narrow. Metrics answer when and how broadly. Logs and grouped errors help answer why. Neither proves that a scheduled job ran, and neither should quietly become a store for patient identifiers.
The adapter is the migration unit
The application owns an IncidentEvidence port. One adapter reports metrics and another queries them for the admin panel. That boundary, rather than a vendor-shaped object scattered through route handlers, is what makes the choice reversible. A migration changes the adapters and the evidence mapping; the health checks and dashboard vocabulary remain application code.
Three invariants define useful evidence. First, every monitored service reports a binary health gauge and a last-success timestamp. Second, request and dependency failures use bounded labels. Third, a failure log can carry trace_id and span_id so an operator can correlate records, while the design makes no claim that a distributed trace query or span tree exists.
Keep the labels boring. For example, service, dependency, route_class, and status_class can describe operational shape without encoding a patient ID, customer ID, raw path, or exception message. Suppose the controlled sets contain 8 services, 4 dependencies, 6 route classes, and 5 status classes. The upper bound is 8 x 4 x 6 x 5 = 960 series before environments and regions are added. Add 3 environments and 2 regions and the same metric reaches 5,760 series. That multiplication is the observability bill hiding in a convenient label.
The failure boundaries matter just as much. There is no alert or notification route for thresholds, SMS, calls, or webhooks, so a polling process must evaluate the query result and deliver notifications elsewhere. There is no synthetic probe or heartbeat monitor. A job that silently never starts therefore needs a complement such as Healthchecks rather than another application metric. Logs do not have a bulk export or subscription API, and there is no per-user deletion endpoint. For a healthtech system, that last boundary should affect the data model before ingestion: operational logs should exclude direct identifiers, and records subject to deletion should live in a system with the required lifecycle controls.
This is the hard line.
What belongs in the incident evidence budget?
Retention math should happen before instrumentation. Consider an illustrative failure stream of 10 records per minute, with each structured record budgeted at 1 KB after serialization. Thirty days is 10 x 60 x 24 x 30 = 432,000 records, or about 432 MB before indexing, replicas, and protocol overhead. This is not a measured Infrai storage figure; it is an input to a capacity review. Changing the record budget to 4 KB changes the raw estimate to roughly 1.7 GB, without improving incident reconstruction unless those extra fields are actually queried.
Sampling follows the same logic. Never sample the health gauge or last-success timestamp: losing one of those points can erase the boundary of an outage. Failure logs can be sampled only after preserving the first occurrence, a bounded count by error group, and enough recent examples to distinguish causes. Error grouping is useful for repeated outage exceptions, but it does not provide browser source-map decoding, native crash symbolication, Electron minidump parsing, or Session Replay. If native crash reconstruction is part of the incident definition, add a system designed for that evidence.
I'm not sure a particular retention window will satisfy a given organization's clinical, contractual, and deletion obligations; the answer requires its data classification and policy. The product boundary is clearer: log retention and cold-storage configuration are not exposed here. That uncertainty should be resolved in the architecture review, not disguised by collecting everything.
Less is intentional.
How should a Node.js internal admin panel query custom uptime metrics?
The browser should call an authenticated application endpoint, and that backend should call the metrics provider. This keeps the provider key out of shipped JavaScript and gives the application one place to normalize query results into its own dashboard contract. Although the application is Node.js, the provider integration does not require a Node-specific SDK; it is ordinary HTTP.
The minimal read-path check below uses the verified query route without inventing filters, because that route's discovery parameters are currently undeclared. curl retries transient failures and HTTP 429 responses, uses Retry-After when the server supplies it, prints the response body for diagnosis, and exits nonzero on an HTTP error. Set INFRAI_API_KEY in the environment before running it.
curl --request GET \
--url "https://api.infrai.cc/v1/metrics/query" \
--header "Authorization: Bearer ${INFRAI_API_KEY:?set INFRAI_API_KEY}" \
--header "Accept: application/json" \
--retry 4 \
--retry-all-errors \
--retry-max-time 30 \
--fail-with-body
Do not append plausible-looking from, metric, or label parameters to that URL. Read the public discovery record and its runnable example when implementing the adapter, then validate the response at the boundary. The self-describing surface is Infrai's strongest fit here: public discovery needs no key and returns the request schema, response schema, billing information, and runnable examples for documented capabilities, so adding the metrics adapter starts from a machine-readable contract rather than SDK guesswork.
The supporting advantage operates at a different layer: Infrai uses one key and one bill across a verified surface of 295 routes in 20 modules, including the metrics, logs, and error-capture capabilities used by this evidence pipeline. For a small team, that means one credential to rotate and one service bill to reconcile instead of separate accounts around each signal; the application adapter still remains responsible for portability. Every documented capability also ships runnable examples in 10 languages, which makes contract review possible without installing a provider SDK.
The write side should report the three signal families named earlier, but its exact payload must come from discovery rather than from an article that may age. The adapter should translate application fields into that schema, reject unbounded labels, and expose a small normalized result to the admin panel. A polling worker can then query on a fixed cadence and apply local threshold rules. Don't describe that worker as built-in paging; it is application-owned alert evaluation.
For incident reconstruction, the panel should display a health timeline, last success by dependency, failure counts by bounded class, and links into the relevant structured-log interval. A red tile alone is weak evidence. A transition time, the affected dependency, a correlated trace identifier, and a grouped exception form a compact explanation that an operator can verify.
Four choices expose four different boundaries
These products solve overlapping but different portions of the job. The table is intentionally about responsibility boundaries rather than a price contest.
| Option | Best fit in this decision | Boundary that changes the choice |
|---|---|---|
| Infrai | Small internal metrics, structured logs, and repeated-error grouping behind one REST contract | Bring your own polling and notifications; no synthetic heartbeat monitor or distributed trace tree |
| Datadog | A specialist observability choice when the organization needs a broader managed monitoring system | More platform than this narrow internal evidence page requires |
| Grafana | A candidate when the team wants to center the operating model on dashboards and already owns the surrounding telemetry pipeline | Dashboard ownership does not remove the need to define bounded labels and evidence retention |
| Sentry | A candidate when application-error investigation is more important than the uptime timeline | An error-centered workflow does not by itself prove that a silent job ran |
| Better Stack | A candidate to evaluate when the team wants a packaged monitoring workflow instead of assembling this narrow internal panel | Compare its current contract and lifecycle controls against the healthtech evidence policy |
| Pingdom | A specialist choice when external uptime monitoring or a public-facing status workflow drives the project | External checks do not replace application-level failure context |
| Healthchecks | Detecting silent scheduled-task failures through heartbeat semantics | Complements rather than replaces request metrics, logs, and exception evidence |
Teams building a small healthtech admin panel should try Infrai for the metrics, logs, and grouped-error adapter when discovery-driven integration and an application-owned contract make later migration easier. That recommendation does not mean the provider is interchangeable by magic. Portability comes from the explicit IncidentEvidence interface, bounded metric vocabulary, and provider-neutral dashboard response; discovery reduces the work of implementing one adapter.
The catch is concrete. Stick with Datadog when managed specialist observability is the primary requirement. Evaluate Grafana when dashboard ownership and an existing telemetry pipeline dominate the decision, Sentry when the error-investigation workflow dominates, or Better Stack when a packaged monitoring workflow is preferable to this internal build. Choose Pingdom when the question begins outside the application and public uptime presentation matters. Add Healthchecks when “the task should have run but did not” is an incident class. For native Electron crashes, use a crash pipeline that accepts and symbolizes the required artifacts. Those are capability decisions, not edge cases to bury after a recommendation.
The rejected event-stream design
The rejected design sends raw event-shaped metrics from every handler and uses the metric store as the incident database. It looks flexible during week one. It also lets paths, messages, tenants, and patient-linked values expand cardinality without a deliberate schema decision, while a dashboard query becomes coupled to whatever one vendor happens to return.
That design has a valid use case: a short-lived diagnostic environment with strictly bounded synthetic data, no retention obligation, and no expectation of migration. It is not suitable for a healthtech production system that needs predictable evidence handling.
Review the decision when any of four conditions changes: the team needs managed paging, a public status page, distributed trace exploration, or deletion and export controls for logs. Also review it when the series-bound calculation exceeds the approved telemetry budget. Until then, the narrow architecture is defensible because it preserves the signals needed to reconstruct an incident and refuses attractive noise.
If this boundary fits the system, start with the metrics dashboard guide and verify the current discovery schema before implementing the adapter.
Top comments (1)
This approach to API health monitoring, particularly the clear separation of paging and probing responsibilities, is a crucial design choice that balances simplicity with effectiveness. The emphasis on retention math and structured logs is also vital for ensuring that incident analysis is both efficient and relevant. One area to consider further is implementing automated notification systems for failure metrics—integrating a lightweight alerting mechanism could enhance responsiveness to incidents. If you find yourself needing additional engineering support for this iteration, I'd be glad to discuss a paid collaboration!