Fly.io is one of the most developer-friendly platforms for deploying containerised applications globally. Its rolling deployments, automatic rollbacks, and built-in health checks make it a compelling choice for production workloads. But if you're relying on Fly.io's internal checks as your entire monitoring strategy, you're missing a critical piece of the reliability picture.
This article explains the gap between Fly.io's built-in infrastructure checks and external uptime monitoring — and how to set up Vigilmon alongside Fly to close it.
What Fly.io's Health Checks Actually Do
Fly.io health checks are designed to serve one purpose: help Fly decide whether to route traffic to a VM. When you define a health check in your fly.toml, Fly's load balancer uses it to determine if a newly deployed machine is ready to receive requests, and whether a running machine should be pulled from the rotation.
This internal feedback loop is genuinely useful. Combined with rolling deployments and automatic rollback, it means bad deploys often stop themselves before users notice. That's a meaningful reliability feature.
What it is not, however, is external uptime monitoring from your users' perspective.
The Monitoring Gap Fly.io Doesn't Cover
Fly's health checks are infrastructure-internal. They answer the question: is this machine healthy from Fly's network perspective? They don't answer: is my application reachable and performing correctly for users on the public internet?
Here's what Fly.io's built-in checks cannot tell you:
No external uptime probing. Fly's health checks originate from within Fly's own infrastructure. If there's a routing issue between your users and Fly's edge, a regional Fly network disruption, or a DNS misconfiguration on your domain, your app can appear healthy inside Fly while being completely unreachable to users.
No alerts when your Fly app is down from a user perspective. Fly's health system is silent to you as an operator unless you're watching a dashboard. There are no email, Slack, or webhook alerts when your app stops responding to public requests.
No SSL certificate expiry monitoring. Fly manages TLS termination and can provision certificates, but it doesn't alert you when a certificate is approaching expiry on a custom domain — especially if you're managing certificates outside Fly's ecosystem.
No TCP port checks. If you're running non-HTTP services on Fly — a TCP proxy, a database, a game server, a messaging daemon — Fly's HTTP-centric health checks provide no visibility into whether those ports are reachable from the internet.
No heartbeat monitoring for Fly scheduled machines. Fly Machines can run on a schedule (using fly machines run with a cron-like pattern). If a scheduled machine silently fails, stops executing, or hangs, you won't know unless something downstream breaks.
Why External Monitoring Is Necessary for Fly Apps
The distinction matters most at the worst times. Here are common failure scenarios where Fly's internal checks stay green while your users experience an outage:
- DNS propagation issues after changing custom domain settings — Fly sees the app as healthy, but users get NXDOMAIN errors
- Fly regional network events — one of Fly's edge regions develops connectivity issues; traffic routed through that region fails while Fly's internal checks run on healthy paths
- Rate limit exhaustion or 5xx errors — your application is running and passing TCP health checks but returning error pages to all users; Fly doesn't consider this a health failure
- Scheduled machine silent failures — a cron job stops running after a code change; no alert fires because the machine technically completed without a crash signal
For each of these scenarios, an external monitor probing your public URL from multiple geographic locations will catch the failure within minutes and alert you directly.
Setting Up Vigilmon for Fly.io Apps
Vigilmon is a developer-first uptime monitor that probes your endpoints from multiple geographic regions simultaneously. An alert fires only when N independent probe nodes all agree the service is unreachable — eliminating false positives from transient network events while ensuring real outages surface immediately.
Step 1: Monitor Your Primary HTTP Endpoint
Add your Fly app's public URL as an HTTP monitor in Vigilmon. This covers the most important check: is your app reachable and returning expected status codes from the public internet?
Set the check interval to 1–5 minutes depending on your SLA requirements. Configure email or webhook alerts to route to Slack, Discord, PagerDuty, or your custom alerting pipeline.
Step 2: Add TCP Port Checks for Non-HTTP Services
If your Fly app exposes non-HTTP ports — a Postgres database, a Redis instance, a TCP game server — add TCP monitors in Vigilmon for each port. This gives you visibility into connectivity at the transport layer, independent of your application health checks.
Step 3: Wire Up Heartbeat Monitoring for Scheduled Machines
For Fly scheduled machines acting as cron jobs, set up a Vigilmon heartbeat monitor. Your scheduled machine sends an HTTP POST to the heartbeat URL at the end of each successful run. If Vigilmon doesn't receive a ping within the expected window, it fires an alert.
This is the only reliable way to know when a scheduled machine stops executing without a visible crash.
Step 4: Configure Webhook Alerts
Vigilmon's webhook support lets you route alerts anywhere. A typical Fly developer setup routes alerts to:
- A personal Slack DM for immediate visibility
- Email as a backup channel
- PagerDuty or an on-call tool for production services with SLAs
Vigilmon + Fly.io: What You Get
| Capability | Fly.io Built-in | Vigilmon | |---|---|---| | Internal machine health checks | ✅ | — | | Rolling deploy validation | ✅ | — | | External HTTP uptime probing | ❌ | ✅ | | Multi-region consensus alerting | ❌ | ✅ | | SSL certificate expiry monitoring | ❌ | ✅ | | TCP port monitoring | ❌ | ✅ | | Cron / scheduled machine heartbeat | ❌ | ✅ | | Email / Slack / webhook alerts | ❌ | ✅ | | Response time history | ❌ | ✅ | | Embeddable status badge | ❌ | ✅ |
The two tools are complementary, not competing. Fly's internal checks ensure your VMs stay healthy within the Fly platform. Vigilmon ensures your application is reachable and performing from your users' perspective — which is the only perspective that ultimately matters.
Getting Started
- Sign up at vigilmon.online — no credit card required, free tier includes 5 monitors
- Add your Fly app's public URL as an HTTP monitor
- Add TCP monitors for any non-HTTP ports
- Set up a heartbeat monitor for each Fly scheduled machine
- Configure alerts to email, Slack, or webhook
Setup takes under 10 minutes. Within one check cycle you'll have external visibility into your Fly.io app that the platform itself can't provide.
Fly.io's internal health checks make your deployments more reliable. Vigilmon makes your application's availability something you can actually depend on — and something you'll know about the moment it changes.
Start monitoring your Fly.io app for free at vigilmon.online.
Tags: #fly-io #monitoring #devops #uptime #sre