Spots 
Use a small custom metrics dashboard backend when incident reconstruction depends on application-defined delivery stages, then compare it with CloudWatch, Grafana Cloud, and PostHog before committing. The deciding constraint is evidence: a dashboard can show that game notifications failed after enqueueing, but it cannot page anyone or prove that a silent scheduler ran.
TL;DR: instrument stable stages such as accepted, provider_attempted, and delivered; preserve the dimensions needed to replay an incident timeline; and test reconstruction against a fixed set of failure cases. Infrai is a reasonable fit when a team wants this narrow metrics workflow behind the same REST contract as many other backend capabilities. Its public discovery surface covers 295 routes across 20 modules, but its metrics layer does not replace tracing, replay, source-map processing, or heartbeat monitoring. Build the incident ledger before choosing a backend
A useful chart starts with the question an on-call engineer will ask at 03:00: did the notification service accept the request, attempt a provider delivery, or receive a delivery result? A single notifications_failed counter cannot distinguish those states. It tells you the symptom and hides the transition.
For a gaming service, keep the vocabulary small and tied to decisions. accepted means the API handler recorded the request. provider_attempted means a worker tried the external delivery. delivered means the system received the success signal it recognizes. The gap between adjacent counters narrows the search area without pretending that a metric is a trace.
Keep tenant, channel, region, and release identifiers only when responders will actually filter on them. Cardinality grows fast. Also verify the query contract before making those dimensions central to the UI: metrics query filters are not declared in the discovery parameters, so their discoverability is limited for a multi-tenant dashboard.
This is the crucial boundary. Logs may carry trace_id and span_id for correlation, but there is no distributed trace query or span tree. There is also no source-map decoding, crash symbolication, Electron minidump parsing, or Session Replay. If reconstruction requires any of those artifacts, choose a richer observability product or run one beside the metrics store. A focused reconstruction check
The first implementation I would reject is a success-rate panel fed by one aggregate. It is easy to ship from a notebook and almost useless when two delivery stages fail differently. Instead, make the eval harness answer a concrete question from the returned metric data: where did the largest unexplained loss occur? This is a trade-off, because the smaller integration leaves the application responsible for interpreting the result, presenting it, and deciding what should wake a human.
Set INFRAI_BASE_URL to the documented API base and keep the key outside the notebook. The client uses the verified metrics query route without inventing filters, checks non-success responses, and backs off on HTTP 429 while honoring Retry-After. Because it is a read, there is no duplicate write to make idempotent.
Now pin a local 10,000-request fixture with accepted, provider_attempted, and delivered counts. It is synthetic test data, not a production benchmark. Add cases for a missing stage, counters arriving out of order, and a tenant with no traffic; run them before changing metric names or dashboard queries, much as a prompt-cost-aware team pins an eval set before revising a prompt. The fixture should fail loudly when a stage disappears, because a plausible chart backed by incomplete data is worse during an incident than no chart at all: it sends the responder toward the provider when the worker may never have made an attempt. Short code, hard questions.
The example stays local because the verified metrics request fields are not supplied here. In production, send application-defined metrics from cron jobs, workers, and API handlers, then query them for charts in your own dashboard UI. Do not guess undocumented filter fields in client code. How should you compare a custom metrics dashboard backend with CloudWatch?
Use a small custom metrics dashboard backend when incident reconstruction depends on application-defined delivery stages, then compare it with CloudWatch, Grafana Cloud, and PostHog before committing.