StillOnline?

Uptime monitoring for developers

Quick answer

Developers on small teams should not babysit production with manual browser tabs. StillOnline provides external HTTP checks, a status page, optional REST API/MCP (Pro+), and webhook-ready workflows via API—so you automate "is it up?" and focus on fixes.

The problem

  • Post-deploy, someone still opens the app "just to check."
  • Staging vs production confusion during incidents.
  • Building an internal uptime cron + status site is a distraction from product work.

How StillOnline helps

  • Register health URLs—StillOnline probes with StillOnline-Probe/1.0.
  • History and incidents on the status page replace Slack archaeology.
  • REST API for CI scripts; MCP for AI editors—see REST API.
  • Public status JSON for internal tools and agents.

Setup in minutes

  1. Add /health (or your stack's equivalent) to StillOnline.
  2. Wire owner alerts to Telegram—the channel you already use.
  3. On Pro, call the API from GitHub Actions after deploy (pattern in API-only SaaS guide).
  4. Link status page from README or internal docs.

When to choose StillOnline

  • You are the default on-call on a tiny eng team.
  • You want API + status page without maintaining Uptime Kuma on a VPS.
  • You already use AI coding tools and may add MCP later.

When not to choose

  • Your org mandates Datadog/New Relic with unified billing.
  • You need custom probe headers or deep synthetic flows on every release (verify roadmap vs marketing).
  • StillOnline does not replace log search or profiling.

FAQ

Can I automate checks from CI?

On Pro/Ultimate, use the REST API to create projects and checks. External scheduled probes still run from StillOnline infrastructure.

What User-Agent do probes use?

StillOnline-Probe/1.0—document this if your WAF filters bots.

Is there a CLI?

Use REST API, MCP, or curl against public status JSON—no separate CLI binary today.

Further reading