Uptime monitor for the Sume API: probe GET /v1/me, spend reads

An uptime check should prove two things: the API answers, and your key still works. GET /v1/me does both, and it is a read. In the rate limit docs, a read is any GET or HEAD, and reads have their own bucket, forty times the plan's write number on the shipped default. Free is 120 writes and 4,800 reads per minute, so a probe every 30 seconds uses two reads a minute.

Never monitor by submitting a tiny generation. That spends the write budget and wallet, and it tests less than the cheap read does.

Probe

It records the status, latency and the ratelimit-remaining header, and treats only 200 as up.

import json, os, time, urllib.error, urllib.request

def probe(base="https://api.sume.com"):
    req = urllib.request.Request(f"{base}/v1/me", headers={"x-api-key": os.environ["SUME_API_KEY"]})
    started = time.monotonic()
    try:
        with urllib.request.urlopen(req, timeout=5) as res:
            status, headers = res.status, res.headers
    except urllib.error.HTTPError as err:
        status, headers = err.code, err.headers
    return {
        "up": status == 200,
        "status": status,
        "ms": round((time.monotonic() - started) * 1000),
        "reads_left": headers.get("ratelimit-remaining"),
        "reset_s": headers.get("ratelimit-reset"),
    }

if __name__ == "__main__":
    while True:
        print(json.dumps(probe()), flush=True)  # one read per probe, no write spent
        time.sleep(30)                          # 2 reads a minute

Read the result correctly

Keep it cheap and honest

• Use a key reserved for the monitor so its budget and revocation are separate from production traffic.
• The shipped read multiple is a deployment setting, so ratelimit-limit on the response is the authority, not the table.
• Routes that need no key exist, such as the health route, but an anonymous check does not prove your key works.
• Alert on consecutive failures, not a single one.