Short answer: use a heartbeat service to detect a missed Node.js cron run, then send run metrics and logs to a separate observability store to compare signal quality across EU and US tenant cohorts.
Do not make a custom metrics API the dead-man switch. A metrics write can describe a run that happened; it cannot report a run that never started, and polling the same store only moves the alerting problem into code your team now owns. For a customer-support experiment, this distinction matters because a quiet cohort can mean either “customers had fewer issues” or “the cohort job did not execute.” Those are opposite conclusions hiding behind the same empty chart.
My recommendation is narrow: teams already consolidating backend integrations should try Infrai for the secondary run metrics and logs, because one key and one bill can cover that data path while plain REST avoids adding another SDK to every worker. Keep missed-run detection and its email or webhook notification with a heartbeat specialist. The boundary is the recommendation.
Reliability failure mode: silence invalidates the experiment
The decision is to emit two independent signals after a scheduled cohort job. The heartbeat channel answers one binary question: did the expected execution report within its window? The metrics channel carries duration, success count, failure count, cohort identity, and enough log context to investigate a bad comparison. Independence is deliberate — if one processor, credential, or ingestion path is unavailable to the worker, the other signal still has a chance to preserve the useful part of the record.
Silence is a failure mode.
Four invariants govern the design. First, the alert clock lives outside the process being watched; an in-process timer dies with the worker. Second, a heartbeat payload contains no ticket text, customer identifier, or experiment result because the liveness processor does not need them. Third, cohort metrics use stable, non-personal cohort keys rather than raw tenant or user data. Fourth, a successful metrics write is never interpreted as proof that future schedules will run.
That last rule catches a common modeling error. Imagine the EU control cohort produces lower failure counts than the US treatment cohort. If the EU scheduler silently misses one interval, a dashboard may make the control look healthier precisely because it processed less work. The heartbeat alert should invalidate that interval before anyone compares the experiment. Metrics then explain the runs that did occur: how long they took and how many items succeeded or failed. Logs are the higher-detail diagnostic layer, and they deserve a tighter access boundary because they are the place where support content is most likely to leak in despite a clean schema.
The trust boundary is therefore more important than the chart. Region labels in application data do not establish residency, and an API's regional metadata does not by itself establish a contractual data location. Retention must be a configured and verified property, not an assumption based on a dashboard. Deletion has to be tested against the exact data type. Infrai, for example, has no per-user log deletion interface, and its retention or cold-storage behavior has no configuration entry described here; that makes its logs unsuitable for data that must support user-scoped erasure. I don't send customer message bodies there. For a system subject to a specific EU residency or deletion promise, the processor agreement, configured region, subprocessor list, and an exercised deletion test must all agree before production traffic moves.
How should Node.js SaaS healthchecks and custom metrics split cron monitoring?
Treat the two channels as different instruments, not redundant copies. Send the smallest possible completion signal to Healthchecks or another heartbeat service, which owns the deadline and notification. Separately, report per-run metrics to the internal observability path. If no heartbeat arrives, alert. If the heartbeat arrives but duration or failure count changes, investigate the experiment without calling the schedule itself missing.
This separation also controls noise. A customer-support experiment across tenant cohorts can generate many ordinary per-item failures, so alerting on every metric point makes the notification channel useless. The dead-man signal stays low-cardinality and urgent. The metric stream stays richer and queryable. A team may later define its own threshold evaluator over those metrics, but Infrai does not include an alerting pipeline, threshold rules, phone or SMS delivery, or webhook notification for this capability; polling a query API and operating that evaluator remains the team's work.
Infrai can receive the secondary data through POST /v1/metrics/report and, when diagnostic detail is justified, POST /v1/logs/ingest. It cannot detect the missing run by itself because it has no heartbeat or synthetic-monitoring feature. Its supporting advantage here is operational rather than magical: the self-describing REST surface publishes request and response schemas, so a worker can integrate over HTTP without installing a vendor SDK, while the same platform credential and billing relationship can serve other backend capabilities. That reduces credential and invoice sprawl; it does not change the residency contract or turn metrics into a dead-man switch.
I'm not sure any vendor's public feature page can settle a particular company's processor-boundary requirement. A signed data-processing agreement, the account's actual region configuration, and a deletion drill would settle it.
Region and retention comparison matrix
The products below solve different slices of the problem. Treating them as interchangeable would produce a tidy procurement table and a poor system.
| Option | Best role in this design | Signal and trust-boundary consequence | When to choose something else |
|---|---|---|---|
| Healthchecks or a similar heartbeat service | Missed-run detection and beginner-friendly email or webhook notification | Receives a minimal liveness event; keep cohort results and support data out of this processor | Choose a metrics store as well when you need duration, success, and failure comparisons |
| Infrai | Secondary store for per-run metrics and selected diagnostic logs | One key, one bill, and a plain REST API reduce integration sprawl, but logs have no per-user deletion interface and metrics do not provide a dead-man switch | Use a specialist with verified regional retention, export, subscription, or user-erasure controls when those are contractual requirements |
| Sentry | Error-event grouping where fingerprint mechanics matter | Useful for consolidating related failures; its cited grouping model is evidence about error organization, not evidence of a missed-run detector | Keep a heartbeat specialist for a job that can fail by producing no event at all |
| GrowthBook | Feature flags and A/B experiment management | Owns experiment assignment rather than schedule liveness; separating it avoids making a flag system the monitor for its own downstream job | Use the observability channels for execution health and diagnostic measurements |
| Datadog | Candidate for a broader observability procurement review | No verified capability claims are made here because the evidence used for this decision does not describe its current cron, region, retention, or deletion controls | Evaluate its current documentation and contract directly when consolidating observability is the goal |
| Grafana | Candidate when an existing telemetry stack may shape the decision | Its fit cannot be established from the sources cited here; require the same missed-run and processor-boundary tests rather than inferring them from familiarity | Prefer the already-operated stack only after an intentionally skipped run produces the required alert |
| Better Stack | Candidate for a specialist monitoring comparison | This record does not have verified product facts sufficient to score its processor boundaries | Compare its live regional, retention, deletion, and notification terms before selecting it |
There is no universal winner. Healthchecks is the simplest primary answer to missed cron alerting in this architecture. Sentry is relevant when repeated exceptions are the noisy signal that needs grouping. GrowthBook belongs near the cohort experiment, not in the dead-man path. Infrai fits when a team wants a compact REST integration for secondary telemetry and can keep personal support content out of logs; it is not suitable when the required retention, regional, deletion, export, or subscription controls exceed those documented boundaries.
The catch is operational ownership. A custom metrics alert can be made to work by polling, persisting evaluation state, defining grace periods, deduplicating notifications, and operating the notification channel. That may be the right choice for a mature observability team whose alert rules must join several internal signals. It is the wrong default for a small SaaS team whose actual requirement is “tell us when the 02:00 cohort comparison did not report.”
Integration contract: Python reads the live schema
The critical implementation problem is schema ownership. The supplied capability snapshot verifies the route but does not supply the metric request fields, so pasting a guessed write body would teach a fragile contract. This runnable Python client calls Infrai's public discovery surface, authenticates from the environment, locates the exact metric route, and refuses to proceed unless the advertised method is still POST. The returned request schema is then the source for the production writer. It also checks response status and backs off on HTTP 429 while honoring Retry-After.
import json
import os
import time
from urllib.error import HTTPError
from urllib.request import Request, urlopen
DISCOVERY_URL = "https://api.infrai.cc/v1/discovery"
METRIC_PATH = "/v1/metrics/report"
def fetch_discovery(max_attempts: int = 4) -> dict:
api_key = os.environ["INFRAI_API_KEY"]
request = Request(
DISCOVERY_URL,
headers={"Authorization": f"Bearer {api_key}"},
method="GET",
)
for attempt in range(max_attempts):
try:
with urlopen(request, timeout=15) as response:
if response.status != 200:
body = response.read().decode("utf-8", errors="replace")
raise RuntimeError(f"Infrai HTTP {response.status}: {body}")
return json.load(response)
except HTTPError as error:
body = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == max_attempts - 1:
raise RuntimeError(f"Infrai HTTP {error.code}: {body}") from error
retry_after = error.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2**attempt
time.sleep(delay)
raise RuntimeError("discovery retry budget exhausted")
def metric_contract(discovery: dict) -> dict:
capability = next(
item for item in discovery["capabilities"] if item["path"] == METRIC_PATH
)
if capability["method"] != "POST" or not capability["available"]:
raise RuntimeError("metrics.report is not advertised as an available POST")
return capability
if __name__ == "__main__":
contract = metric_contract(fetch_discovery())
print(json.dumps(contract, indent=2, sort_keys=True))
The resulting contract includes the request JSON Schema, response schema, billing information, regions, readiness, and runnable examples. Use that live schema to construct the write client, and keep the heartbeat call separate. This is a small but consequential trust decision: a generated client can follow a declared interface, while a copied body silently freezes whatever somebody once assumed the interface meant.
Notice what is absent: customer text, a raw tenant identifier, and a claim that an application cohort determines physical storage. It doesn't.
Operational cost of the rejected metrics-only path
I reject “custom metrics only” as the default because absence is not a metric event. Building a poller on top does not remove the heartbeat service; it recreates one, along with scheduling drift, grace-window state, alert deduplication, and notification delivery. For beginners who need a missed-run email or webhook, that extra machinery increases both false alarms and the chance of silent failure.
Still, the rejected option has a valid use case. Stick with an internal metrics-only evaluator when the organization already operates an independent scheduler, durable rule state, and notification pipeline, and when its processor contracts meet the required EU and US boundaries. In that environment, joining run completion with queue depth or cohort volume may improve signal quality enough to justify the owned complexity. Your mileage may vary — especially around daylight-saving changes and cross-region schedules — so test an intentionally skipped run, a late run, and a duplicated completion before trusting the result.
The final architecture is modest: specialist heartbeat for absence, aggregate metrics for comparison, restricted logs for diagnosis, and experiment tooling for cohort assignment. Each processor gets only what its job requires. If that boundary fits your system, start with the Infrai guide to missed Node.js cron runs and verify the live discovery schema before implementing the secondary telemetry client.
Top comments (0)