--- title: "Website uptime monitoring, free | Logdash" description: "Free website uptime checks every 5 minutes with a Telegram downtime alert, why monitoring the home page can lie, and when Better Stack is the better pick." url: https://logdash.io/monitoring/website --- # Website uptime monitoring Website uptime monitoring requests your site on a schedule, every 5 minutes on a free plan, and alerts you the moment it answers with an error or stops answering, so you hear about downtime before a visitor emails you. Without a monitor, the usual way to learn a site is down is a message from a customer, an hour in. Uptime monitoring replaces that with a request every few minutes from outside your hosting and an alert on the first bad answer. The gap between failure and alert is the check interval: 5 minutes on the Logdash free plan, 1 minute on Builder, 15 seconds on Pro. ## What a free 5-minute check is worth At a 5-minute interval a site gets 288 checks a day, and an outage that starts right after a check goes unnoticed for up to 5 minutes. For a blog or a landing page that is fine. For a checkout it is a support thread, which is the case for Builder at 1 minute or Pro at 15 seconds. Either way the check has to come from outside your hosting. A monitor on the same server as the site goes down with it and tells you nothing. ## What website monitoring catches, and what it misses - Catches: the server answering 5xx, the host refusing connections, a hostname that stops resolving, and no reply within 10 seconds. - Catches: a redirect loop. The check follows up to 5 redirects, so http to https to www is fine and a sixth redirect is down. - Misses: a page that returns 200 but renders blank because a script failed to load. The check reads the status line, not the page. - Misses: wrong text on the page. Logdash has no keyword checks yet. - Misses: a CDN serving a cached 200 while your origin is down. Monitor a route the cache cannot answer. ## The catch-all trap Single-page apps and many hosting setups answer every path with the same HTML and a 200\. Check the home page of such a site and you are checking that the host serves a file, not that your app works. The backend can be down for a day while the monitor shows 100%. Run this to see whether your site does it. terminal ```bash site=https://example.com home=$(curl -sL --max-time 10 "$site/" | cksum) fake=$(curl -sL --max-time 10 "$site/no-such-page-$RANDOM" | cksum) if [ "$home" = "$fake" ]; then echo "catch-all: monitor a health route instead of /" else echo "ok: / is a real page" fi ``` Logdash runs the same test when you add a URL. It requests your address and a made-up path on the same host, and if the bodies match it warns that the check only proves the host is up. It also tries `/health`, `/api/health` and `/up`, and offers any that answer as a one-click swap. ## Website downtime alert in three steps 1. **Add the site** Paste the URL into Logdash. If the catch-all warning appears, take one of the health routes it offers. 2. **Connect Telegram** Link the Logdash bot to your Telegram chat once. Every monitor in the domain can then alert there, and a webhook can run beside it. 3. **Take the site down** Stop the server or point the route at a 500\. On the next check a Telegram message arrives with a red dot, the site name, the status code and the first lines of the error, and a second one when it recovers. ### Logdash vs Better Stack | Feature | Logdash | Better Stack | | ----------------------------------- | -------------------------------- | --------------------------------------------------------------- | | Free monitors and interval | 5 sites every 5 minutes | 10 monitors every 3 minutes | | False alarm filter | Alerts on the first failed check | Checks from at least 4 locations, opens an incident when 3 fail | | Free alert channels | Telegram and webhook | Email and Slack | | Public status page on the free plan | One, custom domain on Pro | One | | Source code | AGPL-3.0, public repository | Closed source | ### When Better Stack is the better pick - You run more than five sites and want them all on a free plan with shorter gaps. - A single failed request from one location should not wake you. Their multi-location confirmation filters that out by default. - You also need SSL certificate or domain expiry checks, which Logdash does not have. ### How does website uptime monitoring work? A server outside your hosting sends a GET to your URL on a fixed interval. A status from 200 to 399 within 10 seconds counts as up. Anything else counts as down and sends an alert on the first failed check, then another when the site recovers. ### What does website monitoring cover beyond uptime? In Logdash, response time on every check, charted per monitor, plus a public status page and uptime badges for 24 hours, 7, 30 and 90 days. It does not check page content, SSL expiry or domain expiry. ### Can I get website uptime monitoring free? Yes. The Logdash free plan covers 5 sites checked every 5 minutes, with Telegram or webhook alerts and one public status page. Builder at $9 a month checks every minute, Pro at $15 every 15 seconds. ### How do I set up a website downtime alert? Add the URL as a monitor, connect a Telegram chat once, then stop the site to test it. The alert arrives on the first failed check with the status code and the start of the error body. ## Keep reading [All monitoring guides](https://logdash.io/monitoring): One page per thing you run, each with the code that makes it checkable and the monitor that watches it. [Webhook monitoring](https://logdash.io/monitoring/webhook): Monitor a webhook receiver with an uptime check on a GET route at the same path, because providers only ever POST to it, and monitor the jobs behind it with a push monitor they call like an inbound webhook, so a missing call becomes an alert. [GraphQL API monitoring](https://logdash.io/monitoring/graphql): Monitor a GraphQL API through a GET readiness route next to /graphql that runs one database query and returns 503 when it fails, because uptime monitors read the status code and a GraphQL server answers 200 even when a resolver throws. [Database availability monitoring](https://logdash.io/monitoring/database): Logdash cannot connect to a database itself, so you monitor database availability through something that can: an HTTP health route that runs select 1 and returns 503 when it fails, or a push monitor called by a script on a host next to the database. [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.