Checkout Cost Ledger: Small SaaS Uptime Monitoring, Health Endpoint, Missed Cron Runs

For a small SaaS checkout running on Node.js, uptime monitoring has to test the health endpoint from outside the application, yet its telemetry bill has to be assigned inside the application. Those are different jobs.

Short answer: use external EU/US uptime probes for the checkout health endpoint, a dedicated heartbeat service for missed cron runs, and app-side metrics for failure context and cost attribution. Infrai can provide that last layer through a plain REST API, with no SDK or client-library lifecycle, and the same key and billing relationship can cover other backend capabilities; it cannot replace synthetic checks, heartbeat monitoring, or alert routing.

This architecture decision keeps the paging signal independent of the system being observed. It also prevents a high-cardinality checkout label set from becoming an expensive substitute for a simple availability test. Cheap matters, but cheap telemetry that cannot see a silent job is false economy.

The decision is to separate detection from diagnosis. An external service decides whether the public health endpoint is reachable from the required geographies. A heartbeat service decides whether a scheduled reconciliation or payment-capture job arrived before its deadline. Application metrics and logs explain which checkout stage failed and which internal cost center owns the signal.

Three invariants make that split useful:

1. A checkout process cannot be its own sole witness. An in-process health metric disappears with the process, while an external probe can still report absence.
2. A missing cron run emits nothing. Detection therefore needs an independently maintained deadline, not a query for an event that never existed.
3. Attribution labels must remain bounded. Region, checkout stage, and outcome can be finite; order IDs, user IDs, cart IDs, and raw URLs belong in logs only when necessary, not in metric labels.

The failure boundaries follow directly. If app-side reporting is unavailable, external probes and heartbeat deadlines still page. If the external uptime vendor is unavailable, internal health signals still support diagnosis, but they do not prove reachability from the EU or US. If the notification path is unavailable, storing another metric doesn't wake anyone.

Keep those boundaries boring.

How should a small SaaS monitor EU/US health endpoints and cron jobs?

Start with the two signals that can disappear completely. Configure an external uptime candidate to request the checkout health endpoint from the EU and US. Give each scheduled job a heartbeat deadline in a Healthchecks-style service. The heartbeat name should represent the job, such as checkout-reconcile, rather than a particular process instance; otherwise every deployment expands cardinality without improving the page.

Then report a bounded app-side metric for each completed checkout stage. A workable dimensional model might have two regions, two outcomes, and four stages. That is 2 x 2 x 4 = 16 time series before replicas or deployment labels. Adding order_id changes the model from a small fixed set into one series per order, which is precisely the cost attribution mistake this design is meant to avoid.

Retention math makes the trade-off visible. At one sample per minute, 16 series produce 16 x 60 x 24 x 30 = 691,200 samples in a 30-day month. This is an input count, not a storage forecast: encoding, indexes, replicas, and vendor retention policy determine actual bytes and cost. If a team instead records one hypothetical 500-byte log for each of 10,000 daily failures, the raw payload alone is about 5 MB per day before indexing and replication. Your mileage may vary because checkout volume and event size vary, but the equation exposes which assumptions need measurement.

Sample successes aggressively if volume requires it; retain failures at a higher rate because they carry diagnostic value. Don't sample the external probe or the missed-run deadline in the same way. Those are sparse decision signals, and dropping one can change an incident from visible to silent.

The cost-allocation matrix includes the query contract

This is not a winner-takes-all comparison. The products occupy different positions in the architecture, and the right purchase depends on which absence must be detected.

The table is deliberately role-based rather than price-led. I don't have authenticated measurements of relative latency, retention cost, or uptime for these candidates, so a numeric ranking would pretend at certainty. Resolve that uncertainty with a short trial using the same EU/US locations, the same probe interval, and the same retention window. Count billable samples and stored bytes; don't compare headline plans with different data shapes.

The practical recommendation is Healthchecks.io for silent schedules plus either StatusCake or Better Stack for external reachability, after verifying the locations and alert path required by the business. Use app-side telemetry beside them. Stick with a consolidated operational suite when one on-call workflow matters more than maintaining clean product boundaries; choose separate specialists when independent failure detection is the stronger invariant.

Datadog and Grafana Cloud also belong on a shortlist when consolidated observability is the objective, while Sentry is a candidate when application error investigation dominates the requirement. This record does not claim feature parity among them. Evaluate each against the same test: independent absence detection, required probe geography, notification ownership, retained bytes, and bounded labels.

The app-side API can report basic success and failure metrics, and a dashboard can be built from metric queries. Because the discovery schema declares no filter parameters for metrics.query, the safe call sends none. Set INFRAI_API_ORIGIN to the documented API origin in the runtime environment; keeping it in configuration also prevents the unlinked comparison from embedding a vendor URL.

curl --request GET \
  --url "${INFRAI_API_ORIGIN}/v1/metrics/query" \
  --header "Authorization: Bearer $INFRAI_API_KEY" \
  --header "Accept: application/json" \
  --fail-with-body \
  --retry 4 \
  --retry-all-errors \
  --retry-max-time 60

The explicit method makes the read path unambiguous. --fail-with-body surfaces a 4xx response instead of treating it as data, while curl's bounded retry behavior covers rate limiting without a tight loop. Production monitoring must still run external health probes independently from both target regions; this query is for a dashboard or a deliberately built notification worker, not proof of regional availability. The API has no built-in threshold rules, phone, SMS, email, or webhook routing.

There is another limit. Logs can carry trace_id and span_id for correlation, but there is no distributed trace query or span tree here. Nor should the checkout design assume source-map decoding, crash symbolication, session replay, log export subscriptions, user-scoped log deletion, or configurable retention and cold storage. Those requirements change the shortlist.

Rejected record: one pipeline owns every signal

The rejected option is a single app-side metric pipeline that reports health, queries its own results, and sends notifications. It looks compact on an architecture diagram. It also shares too many failure modes: a dead process cannot report, a missed job has no event to query, and the notification worker may depend on the same runtime it is meant to watch.

The catch is operational ownership. Building the polling and notification layer can be reasonable for an internal dashboard with no paging obligation, especially when the team already owns a reliable scheduler and delivery system. It is not suitable for checkout availability or payment-job deadlines where silence itself is the signal. In that case, retain the independent probe and heartbeat even if app-side metrics appear complete.

I count a label only when it supports a decision. region can distinguish EU from US reachability; stage can assign a failure to inventory, payment, confirmation, or fulfillment; outcome can split success from failure. A customer identifier may help investigate one event, but putting it on every metric converts customer growth directly into series growth. Put the identifier in a controlled log field, apply the shortest useful retention, and document the deletion obligation before collecting it. The absence of a user-scoped deletion interface is a reason to keep personal data out of this log path, not a reason to improvise around privacy requirements.

That is the ADR: external probes detect endpoint absence, heartbeats detect schedule absence, and bounded app telemetry explains the failure. The architecture costs a little integration work, but every component has one observable responsibility and one defensible owner.

Sources

• https://prometheus.io/docs/practices/naming/
• https://datatracker.ietf.org/doc/html/rfc5424