What to monitor on an API-only SaaS

If customers integrate via REST, webhooks, or API keys, “the site loads” is the wrong signal. Uptime means your API host answers on a dedicated health route — and you publish that truth on a status page.

StillOnline probes public HTTPS URLs and builds a page automatically. Pair it with owner alerts (email, Telegram via the StillOnline bot, or Slack) so you hear from outside your VPC before integrators open tickets.

Quick answer

For API-only SaaS, monitor one public GET /health or /api/health that returns 200 when the product is usable — not the marketing site alone. Register the full HTTPS URL in StillOnline, share the hosted status page in developer docs, and enable owner alerts via the StillOnline bot. Free allows one project and one URL.

Pick one canonical health URL

One URL in README, StillOnline, and sales — fewer arguments during incidents.

Implement once, document in README, register the full HTTPS URL in StillOnline. Deep design: health endpoint design · quickstart.

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

Expect 200 from outside your laptop.

Do not monitor these as “API up”

Wrong targets create green dashboards and angry integrators.

• Marketing landing only — unless landing failure blocks signup you care about.
• OAuth provider status — link their status page instead.
• localhost or private VPC — external probes cannot reach them (OpenClaw / agents need a public health URL first).

Status page for API consumers

Integrators bookmark the status link next to your OpenAPI spec.

1. Create a project named like your product.
2. Add the health check (Free: one URL, 5-minute interval).
3. Share https://stillonline.tech/s/demo in developer docs or API reference.
4. Optional: public JSON at api.stillonline.tech — REST status guide.

Enable Subscribe with Google on the page so integrators get email on incidents.

Alerts for the on-call founder

External probes do not page your team unless you wire owner channels.

1. Settings → Connect Telegram → StillOnline bot → Start.
2. Enable Telegram alerts (or email / Slack). Free: one channel; Pro / Ultimate: all three. Telegram setup.

Down = two failed checks in a row; Telegram repeats on each check interval while down so you do not miss a long outage.

Multiple environments

Free forces prioritization — that is usually correct early on.

Free = one project, one URL. Staging and production need either two projects on Pro or monitor production only and accept staging is invisible.

FAQ

Should a StillOnline health check ping the database on an API-only SaaS?

Only if “API up” must mean “database reachable.” Otherwise use a lightweight /health for fewer false alarms during deploys — health endpoint guide. Pro supports more URLs if you add a deep check.

What URL should StillOnline monitor for webhook delivery issues?

Monitor your ingress URL that must accept inbound webhooks — not each customer’s callback endpoint. One check per critical path on Free; see Pricing.

How do I set up StillOnline for a GraphQL API?

Expose GET /health on the same host as GraphQL, register that HTTPS URL, and share /s/... in API docs. Health check quickstart · public status page.

Can StillOnline probe a health route behind API keys?

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

Where should I put the StillOnline status link for API customers?

Developer docs, README, API reference, or onboarding — share when asked or during incidents. A separate custom domain for the status page is not part of StillOnline — public status page guide.