The worst way to learn your site is down is a message from a customer, because by the time someone bothers to tell you, everyone else has already left. A monitor exists to reverse that order: the machine finds out first, you find out second, and users ideally never notice. Setting one up takes a few minutes and, at the scale most sites need, costs nothing. What is worth thinking about is not the setup, it is what to monitor, and when an alert should actually fire.
What a good check actually is ¶
A monitor that sends one request to your homepage every few minutes answers exactly one question: does that URL answer that request. That is a start, but single requests have a blind spot, they can fail for reasons that have nothing to do with your site being down (a blocked User-Agent, a protocol quirk) and they can pass while something subtler is broken (a certificate about to fail strict validation).
This is why isitdown.io checks every monitored site with 4 independent probe methods in parallel: an HTTP/1.1 request with strict TLS validation, an HTTP/2 request with relaxed TLS, a GET with a real browser User-Agent, and a HEAD with a curl User-Agent. When all four fail, the site is down, full stop. When only some fail, the pattern tells you what changed, a WAF rule that started blocking non-browser clients, an origin that stopped speaking one protocol, a certificate that strict validation now rejects. The full reasoning is in multi-method checks explained.
Alert thresholds: the difference between a signal and a nuisance ¶
The fastest way to ruin a monitoring setup is to alert on every failed probe. Networks blip. Deploys restart processes. A single failed check at 3 a.m. that self-resolves by 3:05 should never wake anyone.
isitdown.io opens an incident only after 2 consecutive failed probes on the 5-minute cadence, and marks it resolved only after 2 consecutive passes. In practice that means an email alert represents a failure that held for roughly ten minutes, not a blip, and the recovery notice means the site has been answering again for two full rounds, not one lucky request. Debouncing in both directions matters: an alert with no matching all-clear leaves you refreshing the site manually, which is the job the monitor was supposed to take.
Email or webhook ¶
Email is the default channel and fine for most sites: an alert when the incident opens, an all-clear when it resolves. Webhook and Discord channels, available on the paid plans, exist for teams that live somewhere else: a webhook fires a JSON payload on every status transition, so you can route it into Slack, PagerDuty, or your own tooling with a few lines of glue. The URL is its own secret, there is no auth handshake to build. (The public "Notify me" card on every check page also accepts a webhook without any account, for one-off watching.)
| Channel | Best for | Failure mode to plan around |
|---|---|---|
| Solo operators, low-traffic sites | Lands in a mailbox nobody watches at night | |
| Webhook | Teams with a chat channel or on-call tooling | The receiving end being down at the same time |
What the numbers mean ¶
Uptime percentages compress a lot of pain into innocent-looking digits. Over a 30-day month:
| Uptime | Downtime per month | What it feels like |
|---|---|---|
| 99% | about 7.2 hours | Users definitely noticed, some left |
| 99.9% | about 43 minutes | One bad incident, or several small ones |
| 99.99% | about 4.3 minutes | Only your monitor noticed |
A 5-minute check cadence resolves outages down to roughly the 99.9% granularity, it can miss a two-minute blip entirely. That is the honest trade-off of any free tier, ours included, and for most sites it is the right one: the outages that cost you users are measured in tens of minutes, not seconds. What a 5-minute cadence reliably catches is exactly the class of incident described in the anatomy of a website outage.
What to monitor besides the homepage ¶
The homepage is usually the most cached, most static, most resilient page you serve, which makes it the least representative thing you can watch. A monitor list that earns its keep looks more like:
- The homepage, as the baseline reachability signal.
- One dynamic endpoint, a search page, an API health route, anything that touches your database, because application failures often return 500 on dynamic paths while static pages keep smiling.
- The login or checkout entry point, the page where downtime costs the most.
- Anything on a different subdomain or host, api.example.com fails independently of www.
Status badges ¶
If your project has a README or a public docs page, a status badge closes the loop for your users: https://isitdown.io/badge/yourdomain.com.svg renders the current probe verdict as an SVG you can embed anywhere. It is free and does not require an account or a monitor.
What the free tier covers, and what paid adds ¶
A free isitdown.io account includes 5 monitors, checked every 5 minutes with all 4 probe methods, with email alerts on every incident and recovery. That is genuinely enough for a personal site or a small project, it is not a crippled trial. Pro ($4.99/month) raises the limit to 30 monitors, adds webhook and Discord alert channels, and removes ads from the site; Max ($12.99/month) raises the limit to 200 for people watching a fleet. The cadence and probe methods are identical on every tier, paid buys capacity, not honesty. Details are on the pricing page.
Common mistakes ¶
- Monitoring only the homepage. Covered above, it is the page least likely to fail.
- Alerting on a single failed probe. You will get woken by blips until you turn alerts off entirely, which is worse than never having them.
- No recovery notification. If the tooling cannot tell you when it is over, you become the recovery notification.
- Watching the wrong layer. If your site sits behind Cloudflare, monitor the public URL users hit, not just the origin, the path between the two is where several failure modes live.
- Trusting one alert channel. If your only alert path is a webhook into a chat workspace, an outage of that workspace silences your monitoring too. Email as a second channel is cheap redundancy.
FAQ ¶
Is a 5-minute check interval fast enough?
For most sites, yes. It bounds detection at five minutes and, with the 2-consecutive-failure threshold, alerting at roughly ten. If a minute of downtime costs you real money, you need paid infrastructure monitoring with second-level probes and an on-call rotation, that is a different product category, and no free tool honestly serves it.
Do I need checks from multiple geographic regions?
Geographic diversity and method diversity answer different questions. Probes from many countries detect regional routing and CDN-edge problems; diverse request types detect UA blocks, protocol gaps, and certificate issues. isitdown.io does the latter, four distinct probe methods from one network vantage, and is upfront about that. If your audience concentrates in a region far from your infrastructure, pairing this with a region-specific check is reasonable.
What exactly counts as "down"?
A probe fails when the request errors (refused, timeout, DNS failure) or returns a server error. An incident opens after 2 consecutive failed rounds and closes after 2 consecutive passes, so brief blips do not page you and recoveries are confirmed, not guessed.