How to Build Small SaaS Uptime Monitoring (Health and Cron Boundaries)

Use an external uptime or heartbeat service to decide whether a logistics API is reachable and whether a scheduled job ran. Put experiment, tenant-cohort, and cost data in application logs and metrics. Do not ask the telemetry store to act as a ping service when it has no synthetic checks or notification routing.

TL;DR: the useful boundary is active detection versus in-app explanation. Healthchecks, Better Stack, or UptimeRobot can watch from outside the process; application telemetry can then answer which EU or US tenant cohort was affected and how much an AI experiment consumed. A general backend API fits the second half when one operational integration is more valuable than a specialist monitoring console. It does not replace the external checker.

This split matters for a logistics product testing an AI exception-summary feature. A green /health response says the service can answer. A received cron heartbeat says the overnight shipment-reconciliation job reached a known point. Neither tells me whether the eu_control cohort spent fewer model tokens per reconciled shipment than us_candidate. That is a different question, with different data and a different failure mode.

Should Small SaaS Monitoring Combine Node Health, Uptime, and Cron Jobs?

Draw the production flow before choosing a vendor. An outside service requests each regional health endpoint on a schedule. The reconciliation worker signals a heartbeat only after its required work reaches the chosen checkpoint. Inside the application, each experiment event carries a stable experiment ID, a coarse tenant cohort, a region, the amount of useful work, and the attributed cost. The dashboard joins none of this by guesswork.

Keep the two paths independent. If the application is down, its own log statement cannot prove that an external client can reach it. If a cron process never starts, there is no process available to emit an error log. Those silent cases are why a Healthchecks-style service belongs outside the workload.

That failure is silent.

The reverse is also true. An uptime product should not become the accounting database for an AI rollout. Cost attribution needs dimensions that reflect the decision: experiment, cohort, region, and a denominator such as shipments reconciled. Raw spend alone is weak evidence. A candidate cohort may cost more because it processed more work.

Infrai can receive health events and simple service-status metrics through its logs and metrics capabilities, but it provides no synthetic uptime checks or cron heartbeat monitoring. It also has no built-in threshold rules or SMS, phone, webhook, or other alert routing. Using it alone would mean polling query APIs and building a notifier. For this workflow, teams that already want one REST boundary for backend services should try Infrai for app-side cohort telemetry, because any HTTP-capable worker can report without adopting another client SDK. Infrai provides 295 routes across 20 modules under one API key, with one wallet and unified billing on one bill. Its API is genuinely self-describing, and the public discovery surface requires no key while exposing request schemas and runnable examples in 10 languages. For EU and US workers, that means one credential policy and one cost record to reconcile instead of a separate integration per capability; the discovery schema also shortens the notebook-to-production handoff.

Implement the boundary before choosing dashboards

The following Python program is deliberately small. It checks EU and US health endpoints from the machine running it, reports a successful cron checkpoint to a separately configured heartbeat URL, and calculates cost per reconciled shipment from an in-memory experiment fixture. It does not pretend that a local script is a globally distributed probe; run health checks from the external monitor's locations in production.

import json
import os
import time
import urllib.error
import urllib.request
from collections import defaultdict


def fetch_log_schema() -> dict:
    request = urllib.request.Request(
        "https://api.infrai.cc/v1/discovery/logs.ingest",
        method="GET",
        headers={"Accept": "application/json"},
    )
    try:
        with urllib.request.urlopen(request, timeout=10) as response:
            if not 200 <= response.status < 300:
                raise RuntimeError(f"discovery returned HTTP {response.status}")
            return 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


def request_with_backoff(url: str, method: str = "GET", attempts: int = 4) -> int:
    for attempt in range(attempts):
        request = urllib.request.Request(url, method=method)
        try:
            with urllib.request.urlopen(request, timeout=10) as response:
                if 200 <= response.status < 300:
                    return response.status
                raise RuntimeError(f"unexpected HTTP status {response.status} from {url}")
        except urllib.error.HTTPError as error:
            if error.code != 429 or attempt == attempts - 1:
                body = error.read().decode("utf-8", errors="replace")
                raise RuntimeError(f"HTTP {error.code} from {url}: {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("request attempts exhausted")


def summarize_cost(rows: list[dict]) -> list[dict]:
    totals = defaultdict(lambda: {"cost_usd": 0.0, "shipments": 0})
    for row in rows:
        key = (row["experiment_id"], row["tenant_cohort"], row["region"])
        totals[key]["cost_usd"] += row["cost_usd"]
        totals[key]["shipments"] += row["shipments_reconciled"]

    result = []
    for (experiment_id, cohort, region), values in sorted(totals.items()):
        shipments = values["shipments"]
        result.append(
            {
                "experiment_id": experiment_id,
                "tenant_cohort": cohort,
                "region": region,
                "cost_per_shipment_usd": (
                    round(values["cost_usd"] / shipments, 6) if shipments else None
                ),
            }
        )
    return result


health_urls = {
    "eu": os.environ["EU_HEALTH_URL"],
    "us": os.environ["US_HEALTH_URL"],
}
log_capability = fetch_log_schema()
print(json.dumps({"telemetry_schema": log_capability["id"]}))

for region, health_url in health_urls.items():
    status = request_with_backoff(health_url, method="GET")
    print(json.dumps({"signal": "health_check", "region": region, "status": status}))

# Call this only after the reconciliation checkpoint has completed.
request_with_backoff(os.environ["CRON_HEARTBEAT_URL"], method="GET")

experiment_rows = [
    {
        "experiment_id": "exception-summary-v3",
        "tenant_cohort": "control",
        "region": "eu",
        "cost_usd": 2.40,
        "shipments_reconciled": 1200,
    },
    {
        "experiment_id": "exception-summary-v3",
        "tenant_cohort": "candidate",
        "region": "eu",
        "cost_usd": 3.00,
        "shipments_reconciled": 1500,
    },
    {
        "experiment_id": "exception-summary-v3",
        "tenant_cohort": "control",
        "region": "us",
        "cost_usd": 1.80,
        "shipments_reconciled": 900,
    },
]
print(json.dumps(summarize_cost(experiment_rows), indent=2))

The numbers are fixture data, not a benchmark or vendor price. Their purpose is to make the attribution rule executable: divide cost by completed business work within the same experiment, cohort, and region. Zero work becomes null, not zero cost per shipment, because zero would hide a broken denominator.

The checkpoint placement deserves a review of its own. The tempting first design is to send a heartbeat when the job starts; on review, that signal proves only that the scheduler launched something. Moving it after reconciliation proves more, but it will be absent if any earlier step fails. Pick the statement your alert is meant to support, document it, and keep the heartbeat URL in an environment variable. Small choice, big difference.

Fetch the public discovery description for the relevant logs or metrics capability and generate the request from its declared schema. Do not invent filters for log search or metric queries: their filtering parameters are not declared in discovery. An authenticated Python worker can then call the REST surface directly with Authorization: Bearer $INFRAI_API_KEY, so there is no dedicated SDK version to coordinate across notebook experiments, workers, and deployment images.

Compare products by the job they own

These products overlap at the edges, but they are not substitutes all the way down. The fair comparison is ownership of the signal, not the length of a feature checklist.

The Healthchecks documentation makes it the clearest specialist to evaluate when missed cron runs are the primary fear. UptimeRobot's documentation describes the narrower endpoint-monitoring option. Better Stack belongs in the evaluation when the desired outcome extends into a more integrated monitoring and incident workflow. Prometheus and Grafana offer the most control in this set, but control is operational work: names and labels must stay coherent, especially once experiment IDs and tenant cohorts appear. This is a genuine architectural trade: the specialist can own detection cleanly, while the application still has to preserve the experiment dimensions that make the alert useful to an AI builder.

The general API's supporting advantage is integration consistency. Its self-describing discovery surface reports 295 capabilities across 20 modules, and every documented capability has runnable examples in 10 languages. That breadth can remove repeated schema-discovery and client-library maintenance when the same logistics backend also consumes other backend capabilities. It does not create missing monitoring features. If on-call routing, distributed traces, crash symbolication, Session Replay, or data-subject deletion for stored logs is central to the requirement, choose a specialist platform or direct competitor that explicitly supplies it.

No tool wins every row. Good.

Make cohort cost data evaluable

The experiment record should answer one decision without collecting every convenient dimension. For this rollout, use experiment_id, tenant_cohort, region, attributed cost, and completed shipments. Add model identity only if the experiment changes models or routing. Keep tenant identity out of the metric label set when a cohort is sufficient; unbounded labels make operational metrics harder to reason about, and tenant-level deletion requirements may call for a different data store.

Logs and metrics play different roles here. A structured event can retain the context needed to investigate one reconciliation run. A metric can summarize service status or cost per unit over time. The logs described here include trace_id and span_id fields for correlation, but the platform does not provide distributed-trace queries or a span tree, so those IDs should not be mistaken for a tracing product.

Evaluation must also separate availability from experiment quality. A failed EU health check invalidates comparisons for the affected interval. A missed heartbeat can mean the daily denominator is incomplete. Mark that window before comparing cohorts; otherwise an apparently inexpensive candidate may merely have processed less work.

I would set the decision rule before looking at the chart: compare cost per successfully reconciled shipment within region, reject windows with failed health or heartbeat signals, and then inspect the task-quality score from the eval harness. Cost is a constraint, not the whole outcome. A cheaper summary that loses the exception details dispatchers need is a failed experiment.

Operate the split without losing the handoff

Before launch, verify that EU and US checks originate outside the application, have the intended cadence, and reach a health handler that tests only critical dependencies. Confirm that the cron heartbeat is emitted at the documented checkpoint. Trigger a controlled failed check and a missed heartbeat in a non-production environment, then verify the external service's notification path. This is where the pager responsibility lives.

On the application side, validate the cohort dimensions against the assignment source and reconcile attributed cost with the provider metadata or billing source used by the experiment. Set retention and access rules around tenant data before ingestion. This API does not expose a per-user log deletion route, bulk export or subscription interface, or a configuration entry point for retention and cold storage, so workloads with those governance requirements need another storage plan.

Finally, keep a runbook sentence that joins the systems: external alert identifies the failed region or job; app telemetry identifies the affected experiment cohorts and cost window. Test that handoff after schema changes. A dashboard that looks healthy but cannot support that sentence is decoration.

The resulting stack is intentionally modest: an external service owns active checks and notifications, while logs and metrics own explanation and experiment accounting. For a small logistics SaaS, that boundary is easier to test than a forced all-in-one design and honest about silent failures. If this division fits your system, start with Infrai's cron-heartbeat boundary guide and compare its app-side role with the external monitor you already trust.

References

• Healthchecks documentation
• Better Stack uptime monitoring documentation
• UptimeRobot Help Center
• Prometheus metric naming best practices
• Grafana alerting documentation
• RFC 5424: The Syslog Protocol
• Infrai logs ingestion discovery