StillOnline?

API health endpoint monitoring

Quick answer

StillOnline API monitoring is an HTTP uptime check aimed at your GET /health, /api/health, or /ready URL—not a separate synthetic transaction product. External probes expect a status code (usually 200) on a schedule. Free: 1 URL; Pro adds more URLs and faster intervals. Pair with a status page and REST API on paid plans.

Benefits

  • One canonical health URL — document it once; monitors and agents use the same contract.
  • Fast failure signal — know when API returns 5xx before customers flood support.
  • Works with any stack — Next.js, FastAPI, Rails, Go—if it is HTTPS and public.
  • Status component — health check appears as a named component on your status page.
  • Agent-friendly — combine public status JSON + MCP on Pro for post-deploy verification.

How it works

  1. Ship a lightweight GET handler (under ~2s, no secrets in body).
  2. Verify with curl from outside your laptop network.
  3. Register the full HTTPS URL in StillOnline.
  4. Set expected status 200 (or your contract).
  5. Enable owner alerts and share the status page.

Stack guides: FastAPI health · health URL quickstart.

Plan availability

Same URL and interval limits as uptime monitoring. SSL and PageSpeed checks share the per-project check quota.

FAQ

Is API monitoring different from website monitoring?

In StillOnline they use the same HTTP check type. The difference is intent—you monitor an API health route instead of a marketing homepage.

Can I validate JSON fields in the response?

Not as a built-in check type today. Use HTTP status + optional manual review, or extend health logic in your app.

Should I use /health or /ready?

Use one URL consistently. /health for liveness; /ready only if you accept false negatives during deploys.

Does StillOnline monitor POST or authenticated endpoints?

Checks are GET to public URLs without custom auth headers in v1. Protected routes need a dedicated public health path.

Further reading