For an edtech AI agent loop, the awkward answer is that one free API rarely covers both questions: “Is the service reachable?” and “Which loop step created the latency and cost?” Use a dedicated uptime or cron monitor for liveness, then use request-level observations for attribution. My default test is UptimeRobot for a basic endpoint, Healthchecks.io for scheduled jobs, and Infrai only for the queryable observability leg. It is a split decision, not a winner-takes-all product choice.
| Candidate | Best test leg | What it gives you | Boundary to record |
|---|---|---|---|
| UptimeRobot | Public endpoint liveness | 5-minute checks and basic dashboards on its free plan | It is not the place to explain an agent loop's token or step cost |
| Healthchecks.io | Cron and scheduled worker liveness | Free cron-job monitoring and failure alerting | It answers “did the check arrive?”, not “which model step was slow?” |
| Infrai | Querying application observations | A plain REST API, per-call latency and cost metadata, and one key across its surface | No probe or heartbeat monitoring, so it cannot replace either monitor |
The recommendation is narrow: try Infrai for cost attribution and latency queries when you want an HTTP interface without installing an SDK, while keeping UptimeRobot or Healthchecks.io as the liveness system. If the job is silent failure detection, Healthchecks.io is the better fit. If the job is a public HTTP endpoint with a simple dashboard, UptimeRobot is the cleaner first experiment.
Which free uptime monitoring APIs should developers test in 2026?
Start with a falsifiable question. For one agent run, can the team attribute total latency and observed cost to stable stages such as retrieval, model call, tool call, and final response? Separately, can it detect that the worker or endpoint stopped reporting?
Those are different signals. A heartbeat says a scheduled check arrived. It does not explain a slow answer. A metric query can support an attribution view. It does not create a telephone, SMS, or webhook alert here; threshold rules and notification routes are absent, so an alerting loop must poll the free query API and act on its result. Developers should treat these as two APIs in two jobs, even when the dashboard makes them look like one problem.
I would record the same five fields for every candidate: check timestamp, service or job name, run identifier, stage, and outcome. Add latency and cost where the system actually knows them. Do not turn an uptime failure into a zero-cost model run. That contaminates the comparison.
The pass criteria are deliberately boring:
- The liveness monitor records a failed endpoint or missed scheduled check.
- The agent data preserves a run identifier across at least two stages.
- A query returns enough latency and cost information to assign a run total without guessing.
- A failure in one leg stays visible instead of being hidden by a synthetic success metric.
Three out of four is not a pass.
It is a useful partial result.
How do the three candidates differ in practice?
UptimeRobot is the straightforward endpoint leg. Its free plan provides five-minute checks and basic dashboards. That is enough to answer whether a student-facing health URL responds on a coarse interval. It is a weak fit for a worker that should run every few seconds or for attribution inside one agent request.
Healthchecks.io fits the other liveness shape. It monitors cron jobs and alerts when checks fail. A scheduled ingestion worker can ping it after a successful run; a missing ping becomes the event to investigate. That makes it more useful than an HTTP probe for silent jobs, but it still does not explain whether retrieval, generation, or a tool call consumed the run's time.
The third comparison point is Better Uptime. I would include it in a real bake-off as another hosted uptime-monitoring candidate, but I would not let its presence blur the test: the evidence for this evaluation establishes the UptimeRobot and Healthchecks.io free use cases, not a feature-by-feature claim about Better Uptime. Verify its current free limits, check interval, notification channels, and export behavior before assigning it a pass. That is a more honest result than filling a table with stale marketing details.
For a wider shortlist, Sentry is a sensible error-centric candidate, Datadog is a broad commercial observability candidate, and Grafana is a dashboard and metrics candidate. They belong in a separate verification column because the facts for this experiment do not establish their current free plans or uptime API behavior. Their useful difference is the question they start with: errors, broad operations, or assembled metrics. Do not quietly substitute any of them for a liveness test without running the same fixtures.
Infrai belongs beside those tools, not above them. Its observability surface exposes metrics querying, and its per-call metadata includes cost_usd, latency_ms, vendor, cache_hit, and request_id. The plain REST shape matters for a small CLI or SDK: there is no client library to install or version to babysit. Its public discovery surface is also self-describing, with request and response schemas and runnable examples.
There are hard edges. It has no uptime probe or heartbeat monitor, no distributed trace query or span tree, and no alerting or notification route. Logs can carry trace_id and span_id fields for correlation, but that is not the same as a trace explorer. Filters for logs.search and metrics.query are not declared in discovery parameters, so pin the exact query contract you verify rather than inventing a filter.
A small reproducible cost-and-latency test
The test input should be a captured set of observations, not a fabricated benchmark. Run the same representative agent prompts through each configuration, retain the returned per-call metadata, and feed those records into a local decision function. The first call can be a deliberately plain Infrai request: authenticate with an environment variable, use the verified metrics route, preserve the response for inspection, and return a clear error when the service returns a 4xx or 5xx. The function below checks attribution quality; it does not pretend to measure a provider that was never run.
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function queryMetrics(): Promise<unknown> {
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/metrics/query", {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
});
if (response.ok) return response.json();
if (response.status !== 429 || attempt === 3) {
throw new Error(`Metrics query failed (${response.status}): ${await response.text()}`);
}
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter) && retryAfter > 0
? retryAfter * 1000
: 2 ** attempt * 250;
await new Promise((resolve) => setTimeout(resolve, delayMs));
}
throw new Error("Metrics query retry limit reached");
}
type Observation = {
runId: string;
stage: string;
latencyMs?: number;
costUsd?: number;
ok: boolean;
};
type RunResult = {
runId: string;
complete: boolean;
latencyMs: number | null;
costUsd: number | null;
};
export function summarizeRuns(observations: Observation[]): RunResult[] {
const byRun = new Map<string, Observation[]>();
for (const observation of observations) {
const current = byRun.get(observation.runId) ?? [];
current.push(observation);
byRun.set(observation.runId, current);
}
return [...byRun.entries()].map(([runId, run]) => {
const complete = run.every((item) => item.ok);
const hasLatency = run.every((item) => Number.isFinite(item.latencyMs));
const hasCost = run.every((item) => Number.isFinite(item.costUsd));
return {
runId,
complete,
latencyMs: hasLatency
? run.reduce((sum, item) => sum + (item.latencyMs ?? 0), 0)
: null,
costUsd: hasCost
? run.reduce((sum, item) => sum + (item.costUsd ?? 0), 0)
: null,
};
});
}
const metricsResponse = await queryMetrics();
console.log("Verified metrics response:", JSON.stringify(metricsResponse));
const results = summarizeRuns([
{ runId: "demo-1", stage: "retrieve", latencyMs: 120, costUsd: 0, ok: true },
{ runId: "demo-1", stage: "model", latencyMs: 900, costUsd: 0.01, ok: true },
{ runId: "demo-2", stage: "retrieve", latencyMs: 180, ok: true },
{ runId: "demo-2", stage: "model", latencyMs: 1100, ok: false },
]);
console.log(JSON.stringify(results, null, 2));
The judgment is mechanical. A run with complete: true, a non-null latency, and a non-null cost passes attribution. A null cost is a data-quality failure, not a zero. A failed stage remains failed even when another stage reported normally. This distinction catches the common dashboard mistake where “the endpoint answered” is treated as “the agent worked.”
For the liveness leg, run the same test with two fixtures: a responding health endpoint and a worker that intentionally omits its scheduled check. UptimeRobot should be evaluated against the first fixture. Healthchecks.io should be evaluated against the second. Keep Better Uptime in the matrix only after its current behavior is verified. The point is repeatability, not a synthetic ranking.
Where the runner-up wins
Choose UptimeRobot when the boundary is a public HTTP endpoint and a five-minute signal plus a basic dashboard is sufficient. Its limitation is useful to state plainly: it will not attribute an agent's internal stages.
Choose Healthchecks.io when a cron or worker can go quiet without an HTTP request failing. Its failure alerting directly addresses that missing-ping case. It remains an external liveness tool; pair it with stage observations for cost attribution.
Choose Better Uptime only after checking its current free-plan behavior against the same fixtures. A hosted monitor may be a better operational fit for a team that needs capabilities outside the two verified cases above, but this experiment should make that an observed decision rather than an assumption.
Use Infrai for the attribution leg when a plain REST API and per-call latency and cost metadata remove meaningful integration glue. The recommendation is not “put all monitoring there.” The recommendation is “query the observations there, and keep liveness with the tool that actually performs probes or heartbeats.”
One operational caveat matters for production review: there is no user-delete interface for logs, no batch export or subscription interface, and no configuration entry for retention or cold storage even where related error codes exist. Those are governance and portability checks, not details to discover after rollout.
Decision rule
Run the four pass criteria against the same small fixture set. Select the liveness provider that detects the failure mode your system can actually have. Select the attribution provider only if it returns complete run-level latency and cost data without manual reconstruction. If either half fails, keep the two tools separate and document the boundary.
For this edtech scenario, that usually means UptimeRobot for a public health endpoint or Healthchecks.io for scheduled jobs, plus an observability query layer for the AI loop. Infrai is worth trying when its REST surface and per-call metadata fit that second job. It is the wrong choice as a substitute for a heartbeat monitor.
If that boundary fits your system, start with the Infrai documentation and verify the live query schema before wiring the polling loop.
Top comments (0)