Sume API uptime monitor: use GET /v1/health, not /health

Use GET https://api.sume.com/v1/health for an uptime monitor. The API reference lists it among the public routes that need no API key, and the unversioned /health is hidden from the public contract.

A healthy response is HTTP 200 with apiVersion, status: "ok", and a build object. It is a liveness check, not a generation check, so a green probe does not prove a paid job will be admitted.

What does the response contain?

In the API code the handler returns apiVersion, status, and build with commit_sha, source_branch, build_id, and build_time. The build block is handy in a status dashboard: you can see when a deploy changed under you.

The OpenAPI example shows apiVersion: "v1" and status: "ok".

Does a green /v1/health mean generation will work?

No. Generation can still return 429 queue_full, 402 insufficient_credits, or 503 provider_capacity_exceeded, per the errors page. Those depend on your workspace balance and capacity, not on API liveness.

For a deeper check, run an authenticated GET /v1/me on a schedule, and read GET /v1/balance before bulk work.

Will the health probe be rate limited?

The route's schema documents a 429 response, so probe at a sane interval and honor retry-after when it appears. Per MDN, Retry-After is either a number of seconds or an HTTP date, and is used with 429 and 503.

A one-minute interval from a single location is plenty for an uptime check.

A probe that alerts on the right things

Fail on non-200 or a status other than ok, and log the commit so you can correlate.

import json, sys, urllib.request

URL = "https://api.sume.com/v1/health"

try:
    with urllib.request.urlopen(URL, timeout=10) as r:
        body = json.load(r)
except Exception as e:
    print("DOWN", e)
    sys.exit(2)

if body.get("status") != "ok":
    print("DEGRADED", body)
    sys.exit(1)
print("OK", body["apiVersion"], body["build"]["commit_sha"][:8])

What Sume does not expose

The health route is intentionally minimal and does not expose provider or queue topology, so there is no public per-provider status endpoint to scrape.

Quick checklist

The points above reduce to a short list you can paste into a runbook.

• Probe GET /v1/health at a modest interval, such as once a minute.
• Alert on a non-200 response or a status other than ok.
• Log build.commit_sha to correlate incidents with deploys.
• Run an authenticated GET /v1/me on a schedule to test your own key.
• Read GET /v1/balance before bulk submissions to avoid 402 mid-batch.