Health endpoint design for SaaS: /health vs /ready

External monitors — including StillOnline — only see an HTTP response on a URL you choose. Good health endpoint design avoids false alarms during deploys and false confidence when the database is dead.

After the route ships, register it in StillOnline, share a status page when customers need transparency, and enable owner alerts via the StillOnline bot on Telegram (guide). Which route you expose is a product call as much as an engineering one.

Quick answer

For most indie SaaS, monitor a lightweight GET /health that returns 200 in under two seconds, without auth or secrets. Register that production HTTPS URL in StillOnline, share the hosted status page when customers ask for status, and enable owner alerts via the StillOnline bot on Telegram or email in settings.

/health vs /ready (Kubernetes semantics, simplified)

Kubernetes popularized liveness vs readiness. Uptime tools do not care about the name — they care whether the URL returns success. The name you pick signals what “up” means for customers.

Indie default: monitor /health with a lightweight check (process only). Use /ready only if marking down during deploys is what you want customers to see on the status page.

Path naming

Consistency matters more than fashion. Pick one canonical path and use it in README, runbooks, and StillOnline.

• GET /health — common for monoliths.
• GET /api/health — API behind /api prefix (API-only SaaS).
• Document the full HTTPS URL — changing paths breaks bookmarks and confuses integrators.

Response contract

Keep the body small and safe to paste in support tickets. StillOnline records HTTP code and latency; humans read the JSON when debugging.

{ "status": "ok", "version": "1.2.3" }

Rules that work well in production:

• 200 when healthy; 503 when unhealthy (some teams use 500 — stay consistent).
• Respond in under 2 seconds.
• No secrets, PII, or stack traces.
• Optional version or commit helps support — not required.

Database and Redis

Deep checks trade honesty for noise. Match depth to what “down” should mean on your public status page.

Auth and networks

External probes run from the public internet, not from inside your VPC.

• Health route should be public without API keys.
• Do not monitor localhost — probes cannot reach it.
• Redirect loops on / — monitor /health directly. Anti-bot sites may show PROBE_LIMITED — see public status page guide.

Wire to StillOnline

Once curl from your laptop (or any outside network) returns 200, add the same URL to StillOnline.

1. Deploy the health route to production.
2. curl from outside your network.
3. StillOnline app → add check → confirm the status page turns green.
4. Settings → Connect Telegram → StillOnline bot → enable alerts.

First-time walkthrough: health check quickstart.

Related guides

• Health check URL quickstart
• API-only SaaS checks
• Monitor on Fly.io
• Public status page guide

FAQ

Does StillOnline use GET or HEAD for health checks?

StillOnline probes with GET by default. Implement a stable GET handler on your health route and use the same URL in README and in the StillOnline dashboard. Walkthrough: health check quickstart.

Should I register only HTTPS URLs in StillOnline?

Yes. Add the same TLS URL customers use in production — http:// redirects often cause false alarms. After probes turn green, share your hosted stillonline.tech/.../s/... link in docs or onboarding when asked — public status page guide.

Should my StillOnline health check ping the database?

Only if “up” must mean “database reachable.” Otherwise a lightweight /health reduces false downs during deploys — design notes in this guide. Pro supports more URLs if you add a separate deep check.

Can StillOnline probe a health route behind API keys?

No — external probes need an unauthenticated health path. Keep keys on business routes only; owner alerts via Telegram StillOnline bot.