---
title: "Fly.io monitoring: health checks and alerts | Logdash"
description: "What Fly.io health checks do, why they never restart a machine or tell you anything, and how to add an outside uptime check with Telegram alerts."
url: https://logdash.io/monitor/fly-io
---

# Fly.io monitoring

Fly.io gives you health checks that steer traffic between machines and Grafana dashboards of your metrics, but nothing that tells you when the app goes down, so pair the fly.toml check with an outside HTTP monitor that sends you a Telegram message.

Fly.io ships two monitoring pieces, and both are good at their job. Service checks in fly.toml stop the Fly Proxy routing to a machine that fails them, and hold back a deploy that never comes up healthy. Metrics land in a managed Prometheus with Grafana dashboards at fly-metrics.net and about 15 days of retention. Neither piece tells you anything. Fly's docs say it plainly: no built-in alerting on metrics, and a failing check does not restart or stop the machine.

## What Fly.io health checks do

A service check under \[\[http\_service.checks\]\] runs at the proxy every 30 seconds by default. Fail it and the proxy marks that machine unhealthy and stops sending it traffic until it passes. That is the whole effect. The machine keeps running, nobody gets a message, and fly checks list is the only place the red shows up. The design assumes two or more machines. A side project on one machine has nothing to route to instead, and you hear about it from a user.

## The check to paste

 terminal 

```bash
# Add a service check to fly.toml, then deploy
cat >> fly.toml <<'TOML'

[[http_service.checks]]
  grace_period = "10s"
  interval = "30s"
  method = "GET"
  timeout = "5s"
  path = "/health"
TOML

fly deploy
fly checks list

# The request an outside monitor makes, through DNS and the Fly edge
curl -s -o /dev/null -w '%{http_code} in %{time_total}s\n' \
  https://your-app.fly.dev/health
```

Point the path at a route that runs one cheap database query and returns 503 when it fails, or it passes every check while the database is gone. The curl line takes the path your users take, through public DNS and the Fly edge. The service check never leaves the platform.

## What Fly.io monitoring leaves out

- Alerts. A message means writing Grafana alert rules, or running your own Prometheus and Alertmanager. The old Slack and PagerDuty check handlers are gone.
- Restarts. A machine failing its check stays up until the app exits with a non-zero code and the restart policy brings it back.
- The outside view. A check inside Fly cannot see a custom domain pointing at the wrong place or a problem between your users and the edge.
- Fly's own incidents. status.flyio.net reports the platform, not your app.

## Fly.io uptime from outside, with machines that auto-stop

An outside check is a request like any other. With auto\_start\_machines on, it starts a stopped machine, and the proxy's stop loop only runs every few minutes, so a 15-second check keeps the app running for good. Logdash gives up after 10 seconds, so a cold boot slower than that reads as down. Either set min\_machines\_running = 1 and pay for one machine that stays up, or check every 5 minutes and accept that some checks measure boot time.

1. **Add the URL** Create a service in Logdash and point its HTTP monitor at https://your-app.fly.dev/health, or the custom domain your users type. Every check stores the status code and response time.
2. **Pick the interval** Every 5 minutes on the free plan, every minute on Builder, every 15 seconds on Pro. 200 to 399 is up. Any other code, or no answer in 10 seconds, is down.
3. **Break it on purpose** Stop the database or deploy a /health that returns 503\. On the next check the monitor flips to down and a Telegram message arrives with the monitor name, status code and error, then another on recovery.

### Logdash vs Fly.io built-in checks

| Feature                                | Logdash                                          | Fly.io                                          |
| -------------------------------------- | ------------------------------------------------ | ----------------------------------------------- |
| Routes traffic away from a bad machine | No, it only watches                              | Yes, that is what service checks are for        |
| Holds back a broken deploy             | No                                               | Yes, deploys wait for checks to pass            |
| Tells you the app is down              | Telegram or webhook on every down and up         | Nothing built in, Grafana alert rules you write |
| Check interval                         | 5 minutes free, 1 minute Builder, 15 seconds Pro | You set it, 30 seconds by default               |
| CPU, memory and OOM data               | Only what your app sends through an SDK          | Built in, about 15 days in Grafana              |
| Price                                  | Free for 5 services                              | Included with the app                           |

### When Fly.io built-in checks is the better pick

- You run two or more machines and only need traffic to avoid a broken one. Fly does that, Logdash cannot.
- You already have Grafana alert rules sending to Slack or email. A second tool adds the outside view and little else.
- You need machine CPU, memory and out-of-memory data. That is Fly metrics, not an uptime monitor.

### What does Fly.io monitoring include? 

Service checks that steer routing and deploys, a managed Prometheus with a Grafana instance at fly-metrics.net, and about 15 days of metrics. There is no built-in alerting, so a down app stays silent until you add Grafana alert rules or an outside monitor.

### Do Fly.io health checks restart a machine? 

No. A machine that fails its service check is marked unhealthy and taken out of routing, but it keeps running until someone restarts it. If you want a restart, make the app exit with a non-zero code when it is stuck and the default restart policy brings it back.

### Do Fly.io health checks send alerts? 

No. fly checks list shows the current state and the old Slack and PagerDuty handlers have been removed. For a message you need Grafana alerting on Fly metrics, or an outside monitor such as Logdash, which sends Telegram or webhook alerts.

### How do I track Fly.io uptime for my app? 

Point an outside HTTP monitor at a health route on your public hostname. status.flyio.net only reports the Fly platform, not whether your app answers. Logdash checks every 5 minutes on the free plan and every 15 seconds on Pro, and keeps the uptime history and response times.

## Keep reading

[All platforms](https://logdash.io/monitor): One page per platform, each with what it already monitors, the gap, and a Telegram alert in three steps.

[Cloudflare uptime monitoring](https://logdash.io/monitor/cloudflare): Cloudflare has no uptime check on the free plan; Health Checks start on Pro at $20 a month billed yearly and probe your origin directly, so to see what users see through Cloudflare you need an outside HTTP check on a health path Cloudflare never caches or challenges.

[Supabase monitoring](https://logdash.io/monitor/supabase): Supabase gives you usage reports, logs and a Prometheus metrics endpoint but no alert when your project stops answering, so deploy an edge function that runs select 1 against Postgres, returns 503 when it fails, and point an outside monitor at it.

[Coolify monitoring](https://logdash.io/monitor/coolify): Coolify watches its own servers and containers - reachability, container stops, disk usage, and CPU and memory through Sentinel - but it never requests your public URLs, so Coolify monitoring needs an outside check on each app and on the Coolify dashboard itself.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.