Health check URL for SaaS — 5-minute quickstart

Before you buy observability platforms, ship one boring thing: a stable URL that returns HTTP 200 when your app and its critical dependencies are alive. External uptime tools — including StillOnline — only see that URL. They do not read your logs.

This guide is stack-agnostic. For platform-specific routes, continue to Vercel or Railway.

Quick answer

Ship one public GET URL (for example /api/health) that returns HTTP 200 in under about two seconds when your app is alive. Verify with curl from outside your network, then register the full HTTPS URL in StillOnline—Free gives one project, one check, 5-minute probes, and a public status page. Turn on owner alerts in settings (Telegram or Slack).

Step 1 — Pick the path

Pick one URL and document it in README, runbooks, and StillOnline—the path is part of your public contract with monitors. Changing it later breaks bookmarks and existing checks.

Common choices:

• GET /health — minimal liveness (process up).
• GET /api/health — API service behind a gateway.
• GET /ready — stricter readiness (DB ping) — use only if you accept false negatives during deploys.

Stick to one canonical URL in docs and monitoring.

Step 2 — Implement a fast handler

The handler should be boring: fast, lightweight (no DB ping), and safe to call from the internet every few minutes. Heavier “readiness” checks belong on a separate route if you need them.

Rules of thumb:

• Respond in under two seconds (StillOnline times out like most monitors).
• Return JSON with { "status": "ok" } or plain ok — consistency matters more than schema.
• Ping Postgres/Redis only if you want downtime when the DB has a brief outage; otherwise keep liveness lightweight and add a separate deep check on Pro if needed.

Do not put secrets, PII, or stack traces in the body.

Step 3 — Deploy and curl from outside

A green check in your browser on localhost does not prove the world can reach the route. Run curl from another network (phone hotspot, CI runner, or a colleague’s machine) before you register the URL.

From any machine not on your laptop:

curl -sS -o /dev/null -w "%{http_code}\n" https://api.yourproduct.com/health

Expect 200. If you get 301, fix redirects (monitors may not follow the chain you expect). If 401, you accidentally protected the health route — loosen it for this path only.

Step 4 — Register in StillOnline

StillOnline will probe the exact URL you paste—no magic discovery of your stack. Create a project, add one check on Free, and wait two or three intervals before you judge red vs green.

1. Start free.
2. New project → name + public status slug (yourproduct).
3. Add check → paste the full HTTPS URL, method GET, expect 200, interval 5 min (Free).
4. Open the generated status page and confirm green after 2–3 probe cycles.

Free: 1 project, 1 URL, 24h history. More URLs, private status, API/MCP: Pricing (Pro $9/mo).

Step 5 — Tell humans and agents

A health URL without a communication path still leaves support guessing. Share the status page where customers already look for answers, turn on owner alerts for yourself, and optionally wire MCP on Pro after infra moves.

• Share the status page link in support docs and developer onboarding.
• Subscribe to email updates on the status page for stakeholders.
• Turn on owner alerts when checks fail or recover: email, Telegram (DM from the StillOnline bot), or Slack (Incoming Webhook). On Free, pick one channel; on Pro / Ultimate, enable all three in account settings. Setup: Telegram · Slack.
• On Pro, wire stillonline-mcp in Cursor to recreate checks after infra churn (MCP post).

What this does not solve

External HTTP checks answer “did this URL return success on a schedule?”—not every failure mode in your stack. Keep these gaps in mind so you do not over-promise on a single /health route.

• SSL expiry — use registrar or dedicated SSL monitors unless you encode it in health (we do not on Free).
• Background jobs only — if users hit the API but workers are stuck, a lightweight /health may lie; add business metrics elsewhere.
• Local agents (OpenClaw) — publish health via tunnel first (OpenClaw guide).

Choosing a vendor? See Best uptime tools 2026.

Related guides

• Telegram owner alerts — mobile DMs when a check goes down.
• Slack alerts via Incoming Webhook — team channel setup.
• Monitor on Vercel · Monitor on Railway — platform-specific health routes.
• Best uptime monitoring for indie SaaS 2026 — tool shortlist.

FAQ

Should StillOnline monitor my root domain or /api/health?

Monitor the URL that defines “product is down” for paying users—usually the API host path (/api/health), not only marketing. StillOnline Free checks HTTP status code on the URL you paste. See public status page guide for where to share the resulting link.

Should my StillOnline health URL return 503 or 200 when the DB is down?

Your choice. 503 marks StillOnline down when the DB is unreachable (honest readiness); a lightweight 200 liveness check avoids noise during brief DB outages. StillOnline Free evaluates status code only—not JSON body fields.

Can StillOnline use HEAD instead of GET for a health check?

StillOnline checks use GET by default. Prefer GET unless you verified your host treats HEAD identically. Most stacks document GET /health—same as Vercel and Railway examples.

How is a StillOnline health URL different from Vercel Analytics?

Vercel Analytics samples traffic and performance; a health URL plus StillOnline gives availability, status page history, and owner alerts. For marketing speed, add Page Speed separately—not on /health.