---
title: "Uptime monitoring for every platform | Logdash"
description: "What Vercel, Railway, Render, Fly.io, Cloudflare, Supabase, Hetzner and 7 more platforms watch for you, what they miss, and the outside check that covers it."
url: https://logdash.io/monitor
---

# Uptime monitoring for every platform

One page per platform, each with what it already monitors, the gap, and a Telegram alert in three steps.

[Vercel uptime monitoring](https://logdash.io/monitor/vercel): Vercel does not request your production domain from outside on any plan, so uptime monitoring on Vercel means a health route that cannot be cached plus an external monitor that calls it every few minutes and alerts you when it stops answering 200.

[Railway uptime monitoring](https://logdash.io/monitor/railway): Railway calls your healthcheckPath only while a new deploy goes live and never after, so uptime monitoring on Railway means an external monitor that requests your public domain every few minutes and alerts you when it fails.

[Render uptime monitoring](https://logdash.io/monitor/render): Render health-checks each instance and can email or Slack you when a service turns unhealthy, but nothing at Render requests your public URL from outside, so uptime monitoring on Render means an external monitor on a /health route.

[Fly.io monitoring](https://logdash.io/monitor/fly-io): 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.

[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.

[Hetzner server monitoring](https://logdash.io/monitor/hetzner): Hetzner Cloud draws CPU, disk and network graphs for every server but sends no alert when one stops answering, so you add an outside HTTP check against a health path on the server or load balancer and route its alert to Telegram.

[DigitalOcean droplet monitoring](https://logdash.io/monitor/digitalocean): DigitalOcean already covers droplet monitoring with free resource alerts once you install its metrics agent and Uptime checks at $1 a month each after the first, so an outside monitor earns its place only for Telegram or webhook alerts, sub-minute checks, or a status page.

[VPS monitoring](https://logdash.io/monitor/vps): VPS monitoring means an outside check that alerts you when the server stops answering, plus a heartbeat from inside that stops when the disk fills or the app dies, because most provider dashboards give you graphs rather than alerts.

[Homelab monitoring](https://logdash.io/monitor/homelab): Homelab monitoring needs two layers, detailed checks inside the lab, usually Uptime Kuma, and one watcher outside it, because a monitor that shares your power, router and internet line goes silent exactly when those fail.

[Raspberry Pi uptime monitor](https://logdash.io/monitor/raspberry-pi): Have the Pi send a heartbeat out to a hosted monitor every 10 seconds from cron, so a crash, a power cut or a dead home connection all end the same way: the heartbeats stop and an alert reaches your phone.

[WordPress uptime monitoring](https://logdash.io/monitor/wordpress): Point an outside HTTP monitor at a URL that has to run PHP and reach MySQL, not only the cached homepage, and send the alert somewhere you read within minutes; no plugin is required.

[Shopify store uptime monitoring](https://logdash.io/monitor/shopify): Shopify keeps its own servers up, so the useful thing to monitor is what Shopify does not watch for you: your storefront on your custom domain and any app or webhook endpoint you host yourself, each with an HTTP check that sends a Telegram alert when it stops answering.