OpenClaw agent availability — external HTTP checks
OpenClaw runs a local Gateway that agents and tools talk to. By default it listens on port 18789 and exposes a lightweight GET /health endpoint so you can confirm the process is up. That is perfect on your laptop. It is not, by itself, a 24/7 external signal when you step away, lose Wi‑Fi, or need customer-facing uptime history.
The built-in openclaw health CLI answers “is my gateway responding right now?” from the same machine or network. StillOnline answers “did the rest of the internet see my agent stack as up, on a schedule, with alerts and a status page?” Those are complementary, not identical jobs.
Quick answer
StillOnline cannot probe 127.0.0.1:18789 directly—publish GET /health on a public HTTPS URL (tunnel, nginx, or VPS edge), then add an HTTP check in StillOnline. You get a status page, probe history, and owner alerts (email, Telegram, or Slack). Keep openclaw health for local debugging; use StillOnline for 24/7 external truth. Free = one URL; more checks on Pro.
What OpenClaw exposes
Typical local check:
curl -sS http://127.0.0.1:18789/health
You should get a fast HTTP 200 while the Gateway is healthy. Official Gateway health docs: docs.openclaw.ai — Gateway health.
StillOnline (and any external monitor) needs a public HTTPS URL that reaches that same path through your edge — not 127.0.0.1 on your desk.
Where teams run OpenClaw
The Gateway process is almost always on localhost:18789; what changes is how you expose /health to the public internet. Most teams fit one of three patterns—pick yours before you paste a URL into StillOnline.
Most setups fall into one of three buckets. The Gateway almost always listens on 127.0.0.1:18789 on the host; the difference is how you expose that to the internet.
| Setup | How OpenClaw runs | What to monitor externally |
|---|---|---|
| Mac mini / home PC | Gateway on the machine 24/7 | Tunnel or reverse proxy to a subdomain (Cloudflare Tunnel, SSH, nginx on a small VPS). A raw home IP is rarely enough: NAT, changing IP, and TLS on bare IP are painful. |
| VPS | Gateway on 127.0.0.1, edge on the same box | https://your-domain/health via nginx/Caddy (recommended). Or https://<public-vps-ip>/health if the port is open, firewall allows inbound probes, and TLS is valid for that URL. |
| Laptop only | Gateway while you work | Same as home when you need 24/7 checks — publish /health through a tunnel; sleeping laptop = external downtime. |
Mac mini note: many people dedicate a Mac mini (or old Mac) as an always-on agent host. Treat it like a home server: local openclaw health + CLI on the LAN, StillOnline on the public URL your tunnel or proxy provides.
VPS + IP: StillOnline accepts public http:// or https:// URLs whose host is a public IP (not 10.x, 192.168.x, or 127.0.0.1). Probes run from the internet, so security groups and firewalls must allow inbound HTTP(S). HTTPS on IP only works if your certificate matches that IP; a domain on the same VPS is usually simpler.
Make /health reachable externally
StillOnline only performs GET requests from the public internet—you are choosing how that request reaches 127.0.0.1:18789. Narrow the exposed surface: one subdomain or path, TLS at the edge, and no admin UI on the same hostname if you can avoid it.
Pick one pattern that matches the table above:
- Reverse proxy (nginx, Caddy, Traefik) on a VPS or home server — terminate TLS, proxy
https://agents.example.com/health→http://127.0.0.1:18789/health, restrict other routes if possible. - SSH tunnel or Cloudflare Tunnel — expose only
/health(or a dedicated subdomain) instead of the full Gateway admin surface. - Dedicated health subdomain — e.g.
https://openclaw-health.yourdomain.com/healthwith IP allowlisting or basic auth in front if your threat model requires it.
Security note: exposing the Gateway broadly increases attack surface. Prefer a narrow path, TLS, and network controls. StillOnline only performs GET checks; it does not authenticate to your agent APIs.
Five steps in StillOnline
Once /health answers on a public HTTPS URL, adding StillOnline is the same flow as any SaaS API: project, check, status page, then owner alerts. The numbered list is the shortest path from zero to a shareable green page.
- Start free — sign in (Google on v1).
- Create a project (name + public status slug).
- Add an HTTP check pointing at your public health URL (expect 200, 5‑minute interval on Free).
- Confirm the auto status page shows green after a few minutes.
- Owner alerts when the check fails or recovers: enable email, Telegram, or Slack in account settings — guides: Telegram · Slack. One channel on Free, all three on Pro / Ultimate. Status page subscribers can still get email via Google sign-in separately.
Free includes 1 project, 1 URL check, 24h history. Need more checks, 90d history, private pages, REST API, or MCP for Cursor/Claude? See Pricing — Pro is $9/mo.
openclaw health CLI vs external monitoring
Run openclaw health when you are on the machine or in CI on your network. Point StillOnline at the public health URL when you need history, a status page, and alerts while you are away. The table summarizes the split.
openclaw health | StillOnline HTTP check | |
|---|---|---|
| Runs from | Your shell / CI on your network | External probes on a schedule |
| Best for | Local debugging, pre-deploy smoke | 24/7 uptime, status page, email subscribers |
| History | Session output | 24h (Free) or 90d (Pro+) |
| Status page | No | Yes, tied to the project |
Use the CLI when you are actively developing. Add StillOnline when “agent gateway down while I sleep” should page someone or show on a public status URL.
Honest limits
StillOnline is not a replacement for full observability (logs, traces, on-call rotations). It will not introspect OpenClaw queues or tool errors — only whether your health URL returns success. If you need dozens of free monitors and no status page, compare UptimeRobot or self-hosted Uptime Kuma.
Related guides
- Health check URL quickstart — publish a public
/healthbefore external checks. - MCP status monitoring for AI agents · MCP docs.
- Telegram owner alerts · Slack alerts.
- Best uptime monitoring for indie SaaS 2026.
FAQ
Can StillOnline monitor OpenClaw at http://127.0.0.1:18789/health?
No. StillOnline probes run from the public internet; localhost and private LAN IPs are rejected. Publish /health behind HTTPS (tunnel or reverse proxy) and point the StillOnline check at that URL—see health check quickstart.
What URL should I add in StillOnline for OpenClaw on a Mac mini at home?
Not a LAN address. Use the HTTPS URL your tunnel or proxy exposes (for example https://openclaw-health.example.com/health). If the tunnel is down, StillOnline marks down even when the gateway is healthy locally—that is the right signal for “can clients reach my agent stack?”
Can StillOnline use a VPS public IP instead of a domain for OpenClaw health?
Yes, if the URL is reachable from the internet and returns 200—for example https://203.0.113.10/health with a valid certificate. StillOnline rejects private IPs and 127.0.0.1. A domain on the same VPS is usually simpler for TLS.
Does StillOnline replace the openclaw health CLI?
No. Keep openclaw health for local checks. StillOnline adds scheduled external probes, status page history, and Telegram or Slack owner alerts.
Will StillOnline show downtime when my tunnel flaps but OpenClaw is up locally?
Yes. If the tunnel or edge is unreachable, external checks fail—that usually matches “users cannot reach my agents.” Fix the tunnel or edge, not only the local gateway process.