What to monitor on Vercel, Railway, and Fly.io
Vercel, Railway, and Fly.io all give indie founders HTTPS and Git deploys, but they hide different failure modes. Platform dashboards answer “did my deploy succeed?” External monitoring answers “can a customer curl the same URL right now?”
This post is a single checklist for all three PaaS hosts. For step-by-step setup, use the dedicated guides linked below — StillOnline works the same on each: one public health URL, hosted status page, and owner alerts through the StillOnline Telegram bot, Slack, or email.
Quick answer
On Vercel, Railway, or Fly.io, monitor one production HTTPS health URL (GET /health or /api/health returning 200) on the hostname customers use — not preview URLs. StillOnline probes from outside each platform every five minutes on Free (one URL; pricing), publishes stillonline.tech/s/..., and sends owner alerts via the StillOnline bot.
Comparison checklist
| What to monitor | Vercel | Railway | Fly.io |
|---|---|---|---|
| Production health URL | Yes — serverless or Node route | Yes — web service hostname | Yes — *.fly.dev or your domain |
| Preview / PR deploy URL | No | No | No |
| Static marketing site only | Only if that is the product | Rarely | Rarely |
| Separate worker with public health | If exposed via HTTP | If worker has public URL | Machines with public route |
| Internal-only networking | No external check possible | No | No — need public HTTPS |
| Platform status page | Inform only | Inform only | Inform only |
Deep dives: Vercel guide · Railway guide · Fly.io guide.
Shared pattern (all three hosts)
The indie setup is identical regardless of PaaS:
- Add
GET /health→ 200, no auth on this path, under two seconds — health endpoint design. curlfrom outside your laptop network, not from the platform shell only.- StillOnline → New project → paste URL → copy status page — health quickstart.
- Settings → Connect Telegram → StillOnline bot — Telegram guide.
Free: one project, one URL, five-minute interval. Pro / Ultimate: more checks and all alert channels — pricing.
Host-specific gotchas
Each platform has quirks that affect false positives — not different StillOnline setup.
| Host | Common gotcha | Mitigation |
|---|---|---|
| Vercel | Serverless cold start on /api/health | Keep handler minimal; avoid heavy DB on every probe |
| Railway | Free tier spin-down | Cold start may fail check — upgrade or accept brief red |
| Fly.io | Machine scale-to-zero, deploy blip | Monitor /health, not / with redirects; see Fly guide |
For redirect and antibot issues on any host: probe redirects guide.
When one HTTP check is enough
For most micro-SaaS before serious multi-region scale, one StillOnline check on the primary API health URL is enough. Add a second check only when you have a separate public hostname customers depend on (e.g. webhook ingestion on another service). See API-only SaaS checks.
Related guides
- Uptime monitoring on Vercel
- Uptime monitoring on Railway
- Uptime monitoring on Fly.io
- Health check URL quickstart
FAQ
Does StillOnline need different setup per PaaS?
Should I monitor Vercel and Railway if I use both for staging and prod?
Monitor production only on Free (one URL). Duplicate staging checks often cause alert fatigue — add a second check on Pro only when staging must page you separately.
Can StillOnline replace each platform’s built-in metrics?
No — and you do not need to. Platform metrics help operators; StillOnline gives external HTTP truth, a customer status page, and owner alerts — public status page guide.
Which health path should I use across all three hosts?
GET /health or GET /api/health returning 200 is the common convention. Match what you document in API reference — health endpoint design.