Uptime monitoring for Fly.io apps
Fly.io manages machine health at the infrastructure layer. SitePulse monitors your app at the application layer — the HTTP responses your users actually receive. 1-minute probes, email alerts on crashes and deploy regressions, and a free public status page. Free for 5 monitors.
What Fly can't see
Fly's health checks confirm that your machine is running and accepting TCP connections. They don't confirm that your application is responding correctly. A machine can be “healthy” in Fly's dashboard while returning 500 on every request because a database migration failed or an env var is missing.
SitePulse sends real HTTP requests to your production URL every minute. If the response status, body, or latency is wrong, you get an email immediately — not after a user files a support ticket.
What to monitor on a Fly.io app
Production URL
Your custom domain or *.fly.dev URL. Catches deploy regressions, machine OOM kills, and application crashes within one probe interval.
/api/health endpoint
A route that checks your database, Redis, and key dependencies. Returns 200 when healthy, 503 when degraded. Separates infrastructure failures from app failures.
Scale-to-zero keep-alive
Using Fly Machines with scale-to-zero? A 5-minute SitePulse probe keeps a machine warm and prevents multi-second cold starts for real users.
Background workers
Expose a health endpoint on your Fly worker process. Workers crash silently — Fly restarts them without alerting you. SitePulse closes that gap.
Fly Postgres health
Add a /api/health/db route that does SELECT 1 on your Fly Postgres cluster. Monitor it. Database degradation is the leading cause of silent Fly app failures.
Public status page
SitePulse's free status page shows your app's 30-day uptime history. Share with users during incidents or embed in your documentation.
Set it up in 60 seconds
- Sign up — free, no credit card.
- Add your Fly app URL (custom domain or *.fly.dev).
- Add /api/health if your app has one.
- Free plan: 5-minute checks. Pro: 1-minute checks ($9/mo).
- Email alert fires the moment a probe fails.
What you get
1-minute checks
On Pro plan ($9/mo). Free plan: 5-minute checks — enough to catch crashes and keep scale-to-zero machines warm.
SSL expiry alerts
Email 14 days before your TLS certificate expires. Fly manages certs for *.fly.dev but custom domain certs need attention.
Public status page
Free on every plan. 30-day uptime history, custom slug, shareable URL. Show users real data during incidents.
Add application-layer monitoring to your Fly app
5 monitors, 5-minute checks, email alerts, public status page — free forever. No credit card.
Frequently asked questions
Fly.io has machine health checks — why use SitePulse too?+
Fly's health checks determine whether to route traffic to a machine — they run at the infrastructure layer. SitePulse runs at the application layer, probing your public URL the same way a real user does. A machine can pass Fly's TCP health check and still return 500 on every HTTP request because of a broken env var, a crashed dependency, or a bad database migration. SitePulse catches application-level failures that Fly's infrastructure checks can't see.
My Fly app is deployed across multiple regions — how does monitoring work?+
SitePulse probes from a single location (Tokyo) and hits your app's anycast address — Fly routes the probe to the nearest healthy region. This tests your global routing and at least one region's health. If a specific region is degraded but others are healthy, Fly usually routes around it automatically. For region-specific monitoring, the most practical approach is to add monitors for region-specific URLs if your app exposes them.
How do I monitor Fly Postgres?+
Don't expose your Fly Postgres instance publicly. Instead, add a /api/health route to your app that does a lightweight database query and returns 200 or 503. Point SitePulse at that endpoint. When Fly Postgres degrades, your health check route will return 503, and SitePulse will email you within a minute.
What about Fly Machines that scale to zero?+
If you're using Fly Machines with scale-to-zero, the first request after idle wakes the machine — this can take 2–10 seconds. SitePulse's probe will see a slow response or timeout depending on your timeout setting. To prevent scale-to-zero from affecting real users, set a SitePulse monitor with a 5-minute interval to keep at least one machine warm.
Can I monitor internal Fly services?+
Only if they have a public endpoint. For internal services accessible via Fly's private network (6PN), you can't directly probe them from outside. The best option is to add a health-check route to your public-facing app that proxies a check to your internal service and returns the result.