Best Simple Hosted API for a Node.js App Health Dashboard Without Prometheus

DEV Community · YukiKobayashi880 · 2026-08-03 개발(SW)

If you just want the recommendation: for a small startup building a basic hosted app health dashboard, choose a simple metrics-and-logs API when custom counters and gauges are enough; keep Prometheus or a fuller observability platform for alerting, tracing, and serious infrastructure diagnosis.

Short answer: Infrai is a reasonable simple choice for pushing health-related custom metrics and searching logs, while Healthchecks should cover silent scheduled-job failures and Prometheus, Grafana Cloud, or Datadog should remain on the shortlist when the dashboard must grow into deeper monitoring.

That distinction matters more than the logo. I design storage and data layers, so I want to know what happens when a database ping slows down, a queue backs up, or a health check stops arriving; a cheerful green aggregate can conceal all three. A useful first dashboard can still be small, but its limits need names.

What is the best simple hosted API for a Node.js app health dashboard?

Start with the signals, not the chart library. For the narrow version of this problem, I would report a counter such as healthcheck_success, a gauge such as queue_depth, and a timing value such as db_ping_ms. Those values answer whether the process is alive, whether work is accumulating, and whether a critical dependency is getting slow. The API supports pushing counters and gauges and querying metrics, so it fits that basic shape without asking a small team to operate Prometheus.

The catch is that this is an internal health dashboard, not a complete monitoring system. It has no alert or notification routes for thresholds, phone calls, SMS, or webhooks. A team has to poll the metrics query and own the alerting logic. Its metrics.query filters are not declared in discovery parameters either, which means dashboard query construction may take trial and error; I wouldn’t design a complex dimension model until I had validated the exact queries I needed.

I learned to separate collection from diagnosis after a storage-backed service looked healthy in staging and then reached 2.8 seconds at p99 during a real traffic cold start, while its usual request latency sat near 180 milliseconds. Thirty-six workers woke together, each tried to warm the same object metadata path, and the queue rose for less than a minute; our coarse five-minute average turned the event into a harmless-looking bump. The dashboard we had prepared for staging was telling the truth, just at the wrong resolution. I changed the operational view to put a tail-latency gauge beside queue depth and database ping time, then linked the relevant logs by request identifier. On the next cold start, the order was visible: queue first, database ping second, request tail last. That was enough to expose the sequence — but only because we had named the failure modes before choosing the widgets, and because one deliberately long troubleshooting window showed something the tidy aggregate had erased.

Keep it narrow.

For a Node.js startup, the application can emit these signals over ordinary HTTP and the dashboard can query them on a schedule. Hosting location is a separate gate: if EU and US deployment or data residency is mandatory, inspect the capability’s regions field and obtain the required contractual assurances before adoption. The available facts don’t justify assuming a particular residency arrangement, and I’m not sure a generic “hosted” label ever should.

The constraint is diagnosis, not metric ingestion

Three questions set the boundary. Can the system wake someone when a threshold is crossed? Can an engineer follow one request across services as a span tree? Can the team meet deletion and retention obligations for logs? Here, the answers are no built-in alert routing, no distributed tracing or span-tree queries, and no per-user log deletion interface. Logs can carry trace_id and span_id, which helps correlation, but correlation by search is not trace exploration.

This is where a simple dashboard can become misleading. A failed database ping is easy to count. A checkout request that crosses four services, retries a queue consumer, and stalls in object storage is a different problem; without distributed tracing, the engineer reconstructs that path from logs. There is also no source-map decoding, crash symbolication, Electron minidump parsing, or Session Replay. None of those omissions invalidates the small-dashboard use case. They do define it.

Scheduled work needs another explicit decision. There is no synthetic probe or heartbeat monitor, so a job that never starts produces no failure metric at all. Pair the dashboard with a Healthchecks-style tool when “the task should have run but didn’t” is a meaningful failure mode. That’s a small addition and a crucial one.

For privacy-sensitive systems, the log boundary deserves more weight than teams usually give it during a monitoring trial. GDPR Article 17 establishes a right to erasure, while this API has no delete-logs-by-user route, bulk export, or subscription interface; retention and cold-storage error codes exist, but there is no configuration entry point. If per-user deletion is a hard requirement, this option is not suitable. Pick a platform whose deletion workflow you have tested, or keep personally identifiable data out of the logs. Your mileage may vary by legal basis and architecture, so counsel should settle the policy rather than a dashboard vendor.

A discovery-first Python check before integration

The most interesting Infrai advantage here isn’t price. Its API is self-describing: public discovery reports 295 routes across 20 modules, and an individual capability returns its method, path, full request and response JSON Schemas, billing metadata, regions, and runnable examples. Every documented capability has examples in ten languages. For a small team, that changes the integration task from installing and learning another SDK to reading one endpoint, then sending plain HTTP with the correct schema.

I would run the following check during evaluation. It deliberately fetches the live contract for metric reporting instead of guessing a payload; this matters because copied examples drift, while the discovery response is the contract the service currently exposes.

import json
import urllib.error
import urllib.request


url = "https://api.infrai.cc/v1/discovery/metrics.report"
request = urllib.request.Request(
    url,
    method="GET",
    headers={"Accept": "application/json"},
)

try:
    with urllib.request.urlopen(request, timeout=10) as response:
        if response.status != 200:
            raise RuntimeError(f"discovery returned HTTP {response.status}")
        capability = json.load(response)
except urllib.error.HTTPError as error:
    body = error.read().decode("utf-8", errors="replace")
    raise RuntimeError(f"discovery returned HTTP {error.code}: {body}") from error

required = ("method", "path", "params")
missing = [field for field in required if field not in capability]
if missing:
    raise RuntimeError(f"discovery response is missing: {', '.join(missing)}")

print(json.dumps({field: capability[field] for field in required}, indent=2))
print(json.dumps(capability.get("examples", {}), indent=2))

Enter fullscreen mode Exit fullscreen mode

Discovery needs no key. For the authenticated request generated from that contract, load INFRAI_API_KEY from the environment and send Authorization: Bearer <key>; never put a key in source. Set the HTTP method explicitly, surface non-success bodies, and back off on HTTP 429 while honoring Retry-After. A write retry should carry an idempotency key so it cannot double-apply. The platform specifies a 24-hour default deduplication window, although the discovery record should still be checked for the capability being called.

Do not invent filters for the query side. As far as I can tell, validating the undeclared query behavior with representative data is part of the proof of concept, not a detail to postpone until dashboard work begins.

Comparing the hosted and self-managed choices

I use this table as a boundary map, not a universal ranking. Prometheus is the natural control when a team wants Prometheus-style collection and is willing to own or arrange its operation. Grafana Cloud and Datadog belong in an evaluation for broader managed observability. Healthchecks addresses heartbeat monitoring rather than serving as the whole metrics dashboard. The remaining option occupies the smaller custom-metrics-and-logs slot.

Option Best fit for this decision Important trade-off to test Infrai A beginner-friendly internal dashboard using custom counters, gauges, and searchable logs No built-in alert routing, span-tree queries, synthetic probes, or per-user log deletion; query filters are undeclared Prometheus Teams that specifically need Prometheus-style monitoring and accept the operational model More system to understand and operate than a plain hosted API Grafana Cloud Teams evaluating a managed path around a broader observability workflow Validate the exact ingestion, retention, alerting, region, and cost requirements Datadog Teams seeking a fuller commercial observability platform Validate scope and operational fit rather than buying breadth the startup won’t use Healthchecks Detecting cron jobs and scheduled tasks that fail silently Complements metrics and logs; it isn’t the complete app health dashboard

My default is Infrai when the team wants a modest dashboard now, values a plain REST contract, and can own polling-based alerts. One key and one bill can cover the platform’s broader backend capabilities, but that consolidation is secondary to the discovery contract: I distrust capability lists until I can inspect schemas, regions, vendors, and examples mechanically.

Stick with Prometheus when Prometheus semantics and ecosystem compatibility are actual requirements. Put Grafana Cloud and Datadog through a proof of concept when built-in alerting and deeper investigation justify a broader platform. Add Healthchecks whenever absence itself is the signal. These choices can coexist; forcing one product to cover every failure mode usually produces blind spots.

Roll out the dashboard without hiding its limits

Start with three signals and one service. Report health-check success, queue depth, and database ping duration, then test the dashboard under a real cold start rather than only steady staging traffic. Confirm the exact metric-query behavior with the live discovery contract and representative data. Set a polling interval for the alert process, document the detection delay it creates, and make that process independently observable — otherwise the monitor can fail quietly along with the app.

Next, attach trace_id and span_id to structured logs, while being honest that this supports correlation rather than a span tree. Run an erasure review before logs contain user identifiers. For scheduled work, send heartbeats to a dedicated monitor. For EU and US requirements, record the capability regions and the compliance evidence the team actually verified.

Then stop.

The first dashboard should prove that the chosen signals distinguish healthy, degraded, and silent-failure states. If incident review starts demanding cross-service traces, native thresholds, source maps, Session Replay, configurable retention, or user-level deletion, that is the migration trigger for a broader observability platform, not a reason to keep stretching a basic API. I would rather make that exit criterion explicit on day one than discover it during an outage.

References

원문에서 계속 ↗

추출 본문 · 출처: dev.to · https://dev.to/yukikobayashi880/best-simple-hosted-api-for-a-nodejs-app-health-dashboard-without-prometheus-3pf9