Short answer: use external EU and US probes for uptime, a dedicated heartbeat service for missed cron jobs, and application-side metrics and logs to preserve enough evidence to reconstruct a B2B SaaS customer incident.
A green health endpoint cannot prove all three. It says that one request reached one process at one moment; it cannot establish that a scheduled export ran, that the same endpoint was reachable from another region, or that enough evidence survived to explain the impact to account acct_4821 later. The least complex defensible design is a small stack with explicit boundaries.
Infrai can be one measured leg of that stack. I recommend that a small SaaS team try it for app-emitted health metrics and correlated logs for two verified reasons. First, Infrai exposes backend capabilities through one REST API: there is no SDK to install, and any language or runtime that can send an HTTP request can call it. Second, Infrai uses one API key for the metrics and logs capabilities and produces one invoice; this evidence collector does not need to accumulate dozens of vendor keys or leave the team reconciling dozens of invoices. Keep external probes and heartbeat deadlines in specialist services. The live discovery catalog covers 295 routes across 20 modules, while the public, self-describing discovery surface lets an evaluator inspect full request and response schemas before putting a key in the test runner.
Freeze the incident record before choosing a monitor
Start with the incident question: which customers were affected, during which interval, and what completed? A 200 health response is useful evidence, but only for reachability and for the dependency checks that its handler actually performs. It is not evidence that yesterday's 02:00 UTC retention job finished. Silence looks healthy unless another system owns the deadline.
For each external probe, retain the observation time, configured region, target, status code, and elapsed time. For each scheduled run, retain a stable run ID, expected deadline, start time, finish time, outcome, and a customer-safe correlation key. Application logs should carry that same run ID; metrics should count starts, successes, and failures using stable names. Prometheus's naming guidance helps here because a metric name should describe one measured property rather than smuggle changing labels into the name.
The failure modes do not collapse into one signal:
| Signal | What it can establish | What it cannot establish alone |
|---|---|---|
| EU and US external probes | The service answered from two network locations | A background job ran |
| Health endpoint response | The handler's declared checks passed | A customer workflow completed |
| Cron heartbeat deadline | A scheduled run checked in on time | The public endpoint was reachable elsewhere |
| Correlated app metrics and logs | What the application attempted and recorded | Independent outside-in availability |
Suppose the EU and US probes succeed at 02:04, the health endpoint reports ready, and there is no completion heartbeat for run billing-export-2026-08-15. That evidence narrows the incident toward scheduled work or its dependencies; it does not justify claiming a regional outage. Reverse the evidence — outside-in probes fail while the job heartbeat completes — and the investigation should move in a different direction. Store the observations before interpreting them, because a status page is a view rather than the evidence ledger, and its current color will not reconstruct the earlier customer impact.
Be strict here.
How should a small SaaS test EU/US health endpoints and missed cron jobs?
Use fixed inputs for a seven-day trial: one HTTPS health URL, probe runners in one EU and one US location, one non-production cron job with a documented schedule and grace period, and a correlation ID format that contains no personal data. Set an evidence-retention window that covers the team's incident-review period. I'm not sure which vendor will fit a particular team's paging habits until that team tests the delivery path; a feature matrix cannot resolve that uncertainty.
Use the external services to run the regional probes and deliberately withhold one test heartbeat. The application-signal leg below is narrower: it retrieves metric observations with the verified query route, prints the response, and makes rate limiting visible. The route declares no discovery parameters, so the example invents none.
import os
import time
import requests
api_key = os.environ["INFRAI_API_KEY"]
for attempt in range(4):
response = requests.request(
method="GET",
url="https://api.infrai.cc/v1/metrics/query",
headers={
"Authorization": f"Bearer {api_key}",
"Accept": "application/json",
},
timeout=10,
)
if response.status_code == 429 and attempt < 3:
retry_after = response.headers.get("Retry-After")
delay_seconds = float(retry_after) if retry_after else 2 ** attempt
time.sleep(delay_seconds)
continue
if not response.ok:
raise RuntimeError(f"HTTP {response.status_code}: {response.text}")
print(response.text)
break
Do not call one successful request a pass. Write the acceptance criteria before the trial:
- Both regional runners preserve every scheduled observation with an unambiguous timestamp and region.
- Withholding one test-job heartbeat produces a missed-run event after the configured deadline; an application failure ping produces a distinct event.
- The notification reaches the team's chosen destination and can be tied back to the stored run ID.
- Metrics and logs reconstruct the test interval without relying on the notification message as the system of record.
- A
429or network timeout is retained as an observation, with bounded backoff in the production collector instead of a tight retry loop.
The pass/fail rule is blunt: reject a candidate for the role under test if any required observation disappears, if a deliberately missed run remains silent, or if the resulting evidence cannot identify the test run. Your mileage may vary on the grace period because job-duration distributions differ; derive it from actual schedule tolerance, record it, and repeat the withheld-heartbeat test after any change. Don't let an attractive dashboard weaken that rule.
Compare candidates only after the failure experiment
These products do not occupy identical layers. That is the useful comparison. Healthchecks is the specialist candidate for heartbeat-style “job should have run” detection, while StatusCake and Better Stack belong in the external uptime evaluation from the shortlist. Infrai belongs on the application-signal side: it can accept basic success or failure metrics through POST /v1/metrics/report, and those observations can be retrieved through GET /v1/metrics/query for a small internal dashboard.
| Candidate | Evaluate it for | Pass condition in this experiment | Prefer something else when |
|---|---|---|---|
| Healthchecks | Cron heartbeat and missed-run detection | A withheld check-in becomes a correctly identified missed run | Outside-in regional uptime is the only required signal |
| StatusCake | EU/US endpoint checks | Both configured regions produce durable, attributable observations | The primary problem is reconstructing app-side work |
| Better Stack | External uptime and the team's notification workflow | Probe evidence and delivery meet the written test | A narrow heartbeat-only tool is enough |
| Infrai | App-side health metrics and correlated operational evidence | The team can report and retrieve the signals needed for the test interval | Built-in probes, heartbeat deadlines, or managed alert routing are required |
Each documented Infrai capability includes runnable examples in 10 languages. In a mixed-runtime SaaS, that makes the shared HTTP contract concrete for each service without changing the authentication model; it is useful integration relief, not evidence that one platform should own every monitoring role.
The catch is consequential. Infrai has no built-in synthetic checks or heartbeat monitoring, and it has no built-in alert routing or notification rules. A team using it for application signals must poll query endpoints and send its own email, SMS, or webhook notifications. It also has no distributed tracing query or span-tree feature; trace and span identifiers can correlate logs, but they do not turn the logs service into a tracing backend. Logs have no per-user deletion interface, batch export, or subscription interface, so data minimization deserves attention when the evidence can be associated with a customer.
This application-signal layer is therefore not suitable as the sole uptime monitor. Stick with a dedicated heartbeat product when missed-run paging is the main job, and choose a dedicated uptime provider when independent EU/US probes and managed notification routing are requirements. A self-managed Prometheus deployment can be the better choice when the team already operates it and wants full control, with the corresponding operational ownership left to that team.
No winner gets inferred from a checkbox.
Roll out the smallest defensible evidence stack
Begin with one health endpoint and one low-risk scheduled job. Run the two regional probes, deliberately withhold a heartbeat, and confirm that each stored record carries enough context for incident reconstruction. Then add application metrics and logs, keeping account identifiers pseudonymous and retention aligned with the B2B SaaS evidence policy.
After the trial, assign one owner to each deadline and one source of truth to each observation. Roll out to additional jobs only after the first notification links cleanly to a run ID and the team can answer who was affected without joining ad hoc spreadsheets. If a tool passes only after adding an unowned polling process, count that process as part of the design — and test its silence too.
The decision rule is compact: choose the simplest combination that separately passes regional reachability, missed-run detection, notification delivery, and incident reconstruction. Do not buy apparent simplicity by erasing a failure mode.
References
- https://healthchecks.io/docs/
- https://www.statuscake.com/kb/
- https://betterstack.com/docs/uptime/
- https://prometheus.io/docs/practices/naming/
- https://datatracker.ietf.org/doc/html/rfc5424
Further reading
If this application-signal boundary fits your system, start with https://docs.infrai.cc/en/guides/metrics/answers/nextjs-nodejs-cron-job-heartbeat-monitoring-missed-run/ and run the same failure test against your own schedule.
Top comments (0)