Uptime monitoring for SaaS on Fly.io
Fly.io runs your app close to users with Machines and public *.fly.dev (or custom) HTTPS. The Fly dashboard shows whether your machines are running; it does not replace an external check on the same URL customers curl, and it does not give buyers a status link when API latency spikes region-wide.
StillOnline probes from outside Fly’s network, builds a status page, and can ping you on Telegram through the StillOnline bot when checks fail — before “is it down on your side?” emails land in support.
Quick answer
On Fly.io, expose a public GET /health that returns 200 in under two seconds on the same HTTPS hostname customers use. Register that URL in StillOnline for external probes, share the hosted status page in API docs, and connect the StillOnline bot for owner alerts. Fly’s dashboard metrics do not replace outside HTTP truth.
Step 1 — Expose /health on Fly
Add a lightweight route in your app (Node, Go, Elixir, etc.) that proves the process can answer HTTP without authenticating the probe.
GET /health→200+{ "status": "ok" }- No auth on this path only
- Keep response under 2 s
Deploy with fly deploy, then verify from outside:
curl -sS -o /dev/null -w "%{http_code}\n" https://your-app.fly.dev/health
If you use a custom domain, curl that host — StillOnline should monitor production DNS, not a hostname only Flycast sees internally.
Details: health endpoint design · health quickstart.
Step 2 — Register in StillOnline
When production curl returns 200, paste that exact URL into StillOnline so probes match integrator documentation.
- Start free.
- New project → product name.
- Add check →
https://your-app.fly.dev/health, GET, expect 200, 5 min interval (Free). - Open status page
/en/s/...after green checks and add it to README or onboarding.
Compare hosts: Vercel · Railway.
Step 3 — Owner alerts
Fly metrics do not DM you. In settings:
- Connect Telegram → StillOnline bot → Start
- Enable Telegram alerts (full guide)
Free: one of email / Telegram / Slack. Pro / Ultimate: all three.
Fly-specific pitfalls
Machines that scale to zero, brief outages during deploys, and private flycast networking are the usual mismatches with external monitoring. Always probe a public HTTPS path, ideally /health rather than / with redirects.
| Problem | Solution |
|---|---|
| Machine stopped / scaled to zero | Health fails — expected; document sleep mode or keep one machine warm |
| Brief deploy outage | Short red period — post maintenance or wait for recovery alert |
Internal flycast only | Probes need public HTTPS |
| Redirect loop on root URL | Monitor /health, not / |
Status page in customer docs
Put stillonline.tech/.../s/... in README and API reference so integrators see the same signal you do — public status page guide. Avoid hiding the only status link in the site footer; docs and onboarding are clearer.
Related guides
FAQ
Does StillOnline monitor every Fly.io region separately?
No. StillOnline runs external HTTP probes on one URL per check from its probe network—not multi-region synthetic per region today. Pick the production hostname integrators use; see health endpoint design.
Should StillOnline health checks ping Postgres on Fly?
Only if “up” must mean “database reachable.” A lightweight /health (no DB ping) keeps brief deploy outages smaller; put DB pings in /ready if you want honesty at the cost of noise. Health check quickstart.
Does StillOnline work with Fly custom domains and TLS?
Yes. Register the final HTTPS URL browsers hit—same as your curl test after fly deploy. Then share stillonline.tech/.../s/... in developer docs: public status page guide.