StillOnline?

API monitoring for API-first SaaS

Quick answer

API-first SaaS lives or dies on endpoint availability. StillOnline runs scheduled GET checks against your /health, /ready, or public API routes from external probes, updates your status page, and exposes public status JSON at api.stillonline.tech/v1/public/status/{slug}—no API key required for readers.

The problem

  • Integrators and AI agents call your API—not your marketing homepage.
  • A green dashboard inside VPC does not prove customers can reach you.
  • You need a machine-readable status surface, not only HTML.

How StillOnline helps

  • Point checks at https://api.yoursaas.com/health (or equivalent).
  • Public status JSON for scripts, partners, and agents.
  • Private REST API + MCP on Pro/Ultimate to manage checks from Cursor or CI.
  • SSL certificate expiry checks use the same URL quota.

Setup in minutes

  1. Deploy a simple health route returning HTTP 200 (see health quickstart).
  2. Register that URL in StillOnline.
  3. Document GET /v1/public/status/{slug} in your API docs.
  4. Optional: add MCP tools for post-deploy verification—MCP feature.

When to choose StillOnline

  • Your product is mostly API with a thin web UI.
  • You want status JSON + human status page without building both yourself.
  • You integrate AI coding agents that should read production health.

When not to choose

  • You need synthetic transactions, JSON field assertions, or custom headers on every probe (roadmap items—verify current product before claiming).
  • Deep API analytics (latency percentiles across all routes)—use APM tools.
  • StillOnline checks HTTP availability, not business-logic correctness of every endpoint.

FAQ

Which URL should an API-first product monitor?

Typically a dedicated /health or /ready route that does not require auth. Avoid admin-only paths as your only probe.

Can partners poll status without an API key?

Yes—use the public status JSON endpoint for your project's slug.

Does StillOnline validate JSON response bodies?

Today checks focus on HTTP status and reachability. For JSON-specific patterns, see blog guides and product changelog.

Further reading