Preview

Monitoring

Assertion-based uptime checks for the endpoints you actually care about. Give us a URL and what “healthy” means — a status code, a response header, a string in the body — and we watch it on your schedule and tell you the moment it stops being true.

HTTP(S) today; WebSocket and gRPC on the same engine. No account, no signup — a check belongs to an unguessable siteId you keep to yourself.

A health check is a target + an interval + assertions

“Up” should mean more than “the socket answered.” A check is up only when every assertion you set holds; the moment one fails, the check is down and the report names the assertion that broke — so you learn what went wrong, not just that something did.

Assertion	What it checks	Examples
Response code	The HTTP status, as an exact code or an allowed set/class	`200`; `2xx`; `200,201,204`
Response header	A header is present, equals, or contains a value	`Content-Type` contains `application/json`; `Strict-Transport-Security` present
Body contains	A substring that must appear (or must not appear) in the body	body contains `"status":"ok"`; body does not contain `Exception`

A check is just data — a target, a cadence, and a list of assertions:

{
  "target":   "https://api.example.com/health",
  "interval": 60,                  // minutes: 1 (default) … 1440
  "assert": {
    "status":  "2xx",
    "headers": { "content-type": "~application/json" },
    "body_contains": "\"status\":\"ok\""
  }
}

Three protocols, one engine

HTTP(S)

The full assertion set above — status, headers, body — over HTTP/1.1 and HTTP/2, with redirects and per-request timeouts. Available first.

WebSocket

Open the socket, optionally send a frame, and assert that the expected frame (or an echo) comes back inside the timeout — a real handshake, not just a TCP connect.

gRPC

Speaks the standard gRPC Health Checking Protocol (grpc.health.v1.Health/Check) and asserts the service reports SERVING — the idiomatic way to health-check a gRPC backend.

No account — your `siteId` is the key

Create your first check and you get an auto-generated siteId — a random UUID. That UUID is your credential: anyone who has it can view and edit the checks under it; anyone who doesn’t, can’t. There is no password and no email. A UUID is large enough that it can’t be guessed, so the secret is simply knowing it.

It is the same zero-friction model as our other no-account tools (loxal Notes; the vynx MCP bridge session): an unguessable capability token, not an account. Treat the siteId like an API key — keep it private, share it to delegate access, and “rotate” by moving your checks to a fresh one.

Limit (preview defaults)	Value
Checks per `siteId`	up to 100
Check interval	1 min (default) to 1440 min (24 h)
Sign-up required	none — the `siteId` is minted on first use

On the roadmap

Domain ownership verification

To monitor a domain you’ll prove you own it with a one-time TXT / CNAME DNS record, so a siteId can’t claim a domain that isn’t yours.

Plans & tiers

The 100-check cap and the 1-minute floor become plan-dependent — more checks and tighter intervals on paid tiers; the free tier stays genuinely useful.

Public status pages

A shareable uptime / status page per siteId — a hosted status page without standing up a separate provider.

Alerts

Email and webhook notifications on state change, so a flap from up to down reaches you without you watching a dashboard.

Honest status

Preview, not GA

The data model and limits above describe the service we’re building. There is no public check-creation endpoint yet — this page is the spec, not a live API to call today.

The siteId is a bearer secret

Because the siteId is the only credential, leaking it grants full control of its checks, and losing it means losing access — there is no recovery. That is the deliberate trade for a no-account tool. Keep it safe.

Frequency is best-effort

A 1-minute interval is a target cadence, not a hard real-time guarantee; checks are scheduled with small jitter to spread load. Sub-minute monitoring is out of scope for now.

Want in on the preview?

Tell us what you’d point it at — an API, a site, a WebSocket or gRPC backend — and what “healthy” means for it. We’re shaping the first release around real checks.

Get in touch

Opens your mail client to info@loxal.net. This page is a preview — the Monitoring service is not generally available yet.