Multi-region health check strategy before your first MRR
Multi-region monitoring sounds responsible — probes from Virginia, Frankfurt, and Singapore. For a solo founder on Vercel or Railway with zero revenue, three regions often mean three times the noise and zero actionable fixes.
StillOnline runs HTTP/SSL probes from its worker network (single production probe location today — not a global mesh). This guide helps you decide when one external check is enough, when to add a second URL on Pro, and when paid multi-location tools earn their keep.
Quick answer
Start with one canonical HTTPS health URL in StillOnline — five-minute probes on Free, two consecutive failures before DOWN. That proves “the internet can reach production from outside your laptop,” which catches most indie outages (bad deploy, DNS, expired cert). Add multi-region vendors only when you route traffic by geography, have region-specific SLAs, or post-mortems show “up in EU, down in US” that one probe missed. StillOnline does not offer region picker per check in v1 — honest scope for pre-MRR teams.
One probe vs many regions
| Stage | Recommended checks | Why |
|---|---|---|
| Pre-revenue side project | 1× HTTP /health | Cheap signal; fix deploy/DNS first |
| First paying customers, single region host | 1× HTTP + status page | Customers need transparency, not five continents |
| Multi-region active-active | Multiple external monitors or vendor mesh | Justified when routing is regional |
| Enterprise contract with SLA | Contract-driven probe map | Often beyond StillOnline Free/Pro alone |
Google SRE stresses user-visible symptoms over metric wallpaper — one good health URL beats three redundant alerts to the same on-call phone.
What StillOnline’s single probe catches
- DNS mispoint after migration
- TLS certificate expiry (HTTP + optional SSL check)
- App process down or returning 5xx
- CDN misconfig that blocks external clients
- PROBE_LIMITED (yellow) when antibot blocks the probe — redirects and antibot
What it may miss until you scale:
- Regional ISP path issues affecting only one geography
- Geo-routed DNS sending EU users to a dead PoP while US probe is green
Document that limit in B2B security forms honestly — B2B status trust.
Practical indie stack
- One
GET /api/healthon production API host — health design. - StillOnline HTTP check + public status page + Telegram alert.
- Pro second URL only when you split marketing vs API or add webhook health — webhook monitoring.
- Revisit multi-region after post-mortem or $10K+ MRR with geographic churn.
When to upgrade philosophy (not just plan)
| Signal | Action |
|---|---|
| Repeated “works for me in Berlin” tickets | Add second monitor from another vendor or region |
| Active-active in two clouds | Per-region health + status components |
| Only US-East deploy | Single probe is aligned with reality |
Related guides
- False positive uptime tuning
- Uptime probes and antibot
- Side-project monitoring checklist
- Health endpoint design
FAQ
Does StillOnline check from multiple regions?
Not as a user-selectable multi-region mesh in current prod. One worker network location runs scheduled probes — sufficient for most indie SaaS until geography becomes a product promise.
Should I pay for three regions on day one?
Usually no. Ship one external health URL and a status page first — quickstart.
Can I run two StillOnline checks as a poor man’s multi-region?
StillOnline checks from the same probe network — two URLs help split services (API vs web), not continents.
What interval should I use before adding regions?
Tune interval and false positives on one URL first — false positive guide. Free is fixed at five minutes.