You get a machine to check it for you, every few minutes, from outside your own network. That is all uptime monitoring is. A service requests your page on a schedule, and if it gets the wrong answer or no answer at all, it alerts you. Setting it up takes about twenty minutes.
Almost every client site we take over arrives without it. The team finds out about outages from a customer email, or worse, from a founder refreshing the homepage on a Sunday.
That gap between going down and finding out is the expensive part. The outage costs you an hour. Not knowing about it costs you a day.
Uptime monitoring is an outside service that requests your site on a fixed schedule and records whether it responded correctly. It watches for timeouts, error status codes, missing text, and expired certificates. When something fails, it notifies you through email, Slack, SMS, or a paging tool.
The important word is outside. A check running on your own server tells you nothing, because if the server dies the check dies with it.
Good monitors also check from more than one region. A site that loads fine from London and times out from Singapore is still broken, just not for you.
Less than it sounds. Do the arithmetic on a thirty day month, which has 43,200 minutes. Ninety nine percent uptime allows about 7.2 hours of downtime a month. Ninety nine point nine percent allows about 43 minutes. Ninety nine point nine nine percent allows about 4 minutes.
That is why the extra nines cost so much. Each one cuts your allowed downtime by a factor of ten, and the engineering to get there rises just as steeply.
For most business websites, chasing four nines is a waste of money. What actually matters is how fast you notice and how fast you recover, not whether your annual figure reads 99.9 or 99.95.
Your hosting provider's number is also not your number. If your host is up but your DNS, your form handler, or your payment provider is down, your customer still cannot buy anything. Our guide to choosing web hosting covers what those provider promises really cover.
The pages that make you money and the things that quietly expire. A homepage check catches total outages and nothing else. Add your pricing page, your main conversion page, your form endpoint, your SSL certificate, and your domain expiry.
Keyword monitoring is the underrated one. Instead of only asking whether the page returned a 200, the monitor checks that a specific phrase is present in the response. That catches the failure where your server is fine but your CMS content vanished.
We treat the contact form as a first class monitor on every project. A marketing site with a broken form is technically online and commercially dead, and it can stay that way for weeks before anyone notices.
Certificate expiry deserves its own alert. An expired SSL certificate produces a full browser warning screen, which is worse for trust than a plain outage. It is also completely preventable with a reminder set thirty days out.
Every five minutes is enough for most marketing sites. Every minute is right for anything transactional. Faster checks cost more and mostly buy you a shorter detection window, so match the interval to what a minute of downtime actually costs your business.
UptimeRobot's published pricing is a useful benchmark for what these intervals cost. Its free plan includes 50 monitors at a 5 minute monitoring interval, which is genuinely enough for a small business site.
Their paid tiers buy speed. Solo, at 11 dollars a month billed annually, moves to a 60 second interval. Team, at 39 dollars a month, drops to 30 seconds. Scale, at 83 dollars a month, reaches a 15 second interval with 200 or 500 monitors.
Our view is that most companies should take the free 5 minute checks, cover more endpoints with them, and spend the saved money on fixing the things the monitors find.
Google slows down first, then starts dropping pages. Google Search Central states that "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling." For a short outage that is harmless. For a long one it is not.
The part that should worry you is what comes next. Google's documentation says that "for Google Search, already indexed URLs are preserved in the index, but eventually dropped." A site that stays broken long enough loses its listings, not just its rankings.
Recovery is not instant either. Google says that "once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site." The word gradually is doing real work in that sentence.
This is the argument we use with clients who think monitoring is optional. An outage nobody catches for two days is not just lost sales. It is a slow bleed in search visibility that takes weeks to undo.
A 503, never a 404 and never a 200. Google has said this for years. Returning 503 Service Unavailable tells crawlers the problem is temporary, so they come back instead of concluding your pages are gone.
Google Search Central spelled it out in a post from January 2011 that its current documentation still points to. Instead of returning a 404 or "showing an error page with the status code 200 (OK) when a page is requested, it's better to return a 503 HTTP result code (Service Unavailable) which tells search engine crawlers that the downtime is temporary."
Google also recommends the Retry-After header. The post notes that the expected length of downtime "can be specified in an optional Retry-After header, which Googlebot may use to determine when to recrawl the URL."
The mistake Google calls out is common and quiet. Plenty of sites serve a friendly "Under Construction" page with a 200 status code, which tells Google that the placeholder is the real content. Our post on 404 pages and broken links covers the related habit of returning the wrong code for missing pages.
Start with UptimeRobot for simple availability checks, because the free tier covers what most sites need. Move to Better Stack or Checkly when you want browser level checks that click through a real flow. Use Datadog Synthetics if your team already lives in Datadog.
Cloudflare has health checks built in if your traffic already routes through it, which saves adding another vendor. Pingdom and StatusCake remain solid and have been around long enough to trust.
Alerting matters more than the checking. Route alerts into a Slack channel people actually read, and into PagerDuty if someone is genuinely on call. An alert that only lands in an inbox at 2am is not an alert.
It is also worth subscribing to your vendors' own status pages. Webflow publishes one at status.webflow.com, Vercel at vercelstatus.com, and Cloudflare at cloudflarestatus.com. Knowing the outage is theirs saves an hour of debugging your own code.
Require two consecutive failures before alerting, and separate urgent from informational. A single failed check often means a network blip somewhere between the monitor and your server, not a real outage. Alerting on the first one trains your team to ignore the alerts entirely.
Split your channels by severity. Site down goes to the phone. Certificate expiring in thirty days goes to email. Slow response times go to a dashboard nobody has to react to at night.
Then review the alerts monthly. If the same warning has fired eleven times and nobody acted on it, either fix the underlying issue or delete the monitor. A noisy monitor is worse than no monitor, because it teaches everyone that alerts are noise.
Four monitors and one alert channel. Check your homepage and your main conversion page every five minutes, add a keyword check so you catch empty pages, and add SSL and domain expiry warnings. Send it all to a Slack channel your team already watches. That is a twenty minute job.
Then write down what you will actually do when it fires. Who looks first, where the hosting login lives, and how you put a 503 maintenance page up if you need to. Deciding that during an outage is how short outages become long ones.
If you are launching something soon, fold this into your launch checklist rather than treating it as a later task. Our pre-launch website testing guide covers where it fits alongside the other checks.
If you would rather someone set this up properly alongside the rest of your build, that is something we do on every project we deliver. Tell us what your site does and we will tell you what is worth watching. You can find us at phoenix.studio, and we usually reply within a couple of days.
Tell us where you want to go. We'll tell you how we'd get you there.