Health check URL patterns for SaaS

Quick answer

Indie SaaS teams most often expose GET /health or GET /api/health returning HTTP 200 and a small JSON body (status, ok). /ready appears when teams accept down during deploys (Kubernetes readiness). /status with components[] maps to customer-facing status pages. Probe the same URL you document — quickstart · URL check tool.

Key findings

• /health is the default external probe path in our sample (12 documented examples).
• /ready adds deploy noise unless you want customers to see maintenance.
• Auth on probe URLs breaks external monitors — use public shallow checks.

Methodology

• Sample: Public docs, README health sections, and StillOnline editorial guides (not a statistical crawl of all SaaS).
• Counts = illustrative examples in CSV, not market share percentages.
• Last verified: 2026-06-26.

Data table

Download dataset

CSV with citation URLs: /research/health-check-url-patterns-saas/en/dataset.csv

How to cite

StillOnline (2026). Health check URL patterns for SaaS. https://stillonline.tech/en/research/health-check-url-patterns-saas

FAQ

Should I monitor /health or /ready?

Default /health for customer-visible uptime; /ready only if you want deploys to mark down.

How is this different from the design guide blog?

The blog teaches implementation; this dataset lists patterns and citations.

Does StillOnline care about the path name?

No — any public HTTPS URL returning expected status works.

What JSON should I return?

Small safe JSON under 2s — see design guide.

Can I validate my endpoint before signing up?

Use url-check-now for a one-shot external probe.