Every website goes down eventually. Good hosting, clean deploys, and careful code reduce how often it happens — but they don't change the real question: when your site goes down, how long until you know?
If the answer is "when a customer emails us" or "when someone posts about it," you're paying for downtime twice — once in lost visitors, and again in lost trust. Uptime monitoring fixes that, and setting it up properly takes about ten minutes. This guide applies to any website: a Rails app, a WordPress blog, a static landing page, or an API.
What uptime monitoring actually is
An uptime monitor is a service that requests your site from the outside on a schedule — every minute or every few minutes — and alerts you when something is wrong. The "from the outside" part matters: a check running on your own server happily reports everything is fine while your DNS, TLS certificate, or load balancer is the thing that's broken. You want the same view your users have.
From those checks you get three things: alerts when the site stops responding, an uptime percentage over time, and a response time trend — which is often the more interesting number, because slowdowns usually show up before outages do.
Step 1: Decide what to check
Most people monitor their homepage and stop there. That's a fine start, but the homepage is rarely the page that pays the bills. A better checklist:
- The homepage — your front door, and usually the first thing that breaks visibly.
- The pages that matter commercially — checkout, signup, login, pricing. These can break while the homepage stays green.
- Your API or health endpoint, if you have one — a dedicated endpoint that touches the database is worth far more than a static page that renders even when the backend is on fire. Rails apps get one for free at
/upsince Rails 7.1; on other stacks a simple/healthroute does the same job. - Anything on a different piece of infrastructure — a docs subdomain, a CDN-hosted assets host, an FTP or SFTP endpoint. If it can fail independently, it deserves its own check.
Step 2: Check more than "did it return 200"
Here's the trap almost everyone falls into: a page can return HTTP 200 and still be broken. Error pages served with a 200 status, an empty template, a maintenance page someone forgot to remove — the monitor sees success, your users see a broken site.
The fix is content matching: tell the monitor to look for a specific string in the response — your product name in the footer, a known heading, an "status":"ok" in a JSON health response. If the text isn't there, the check fails even when the status code looks healthy.
For APIs, also match the check to how the endpoint is actually used: a HEAD or GET is fine for pages, but some endpoints only reveal problems on POST, and some need an authentication header sent along with the request.
Step 3: Pick a sensible frequency
Check frequency is a trade-off between how fast you find out and how much noise you generate. Every 1 minute is right for anything revenue-critical: it means you know about an outage in roughly 60 seconds. Every 5 minutes is plenty for marketing sites, blogs, and internal tools. There's rarely a good reason to go slower than that — a check is cheap, and 30-minute intervals can miss short outages entirely.
Step 4: Make the alerts land where you'll see them
An alert nobody reads is the same as no alert. Send downtime notifications to the place your team actually lives — for most teams that's a Slack channel, with email as backup. Two rules keep alerting healthy:
- Alert on recovery too. "It's back up" is as important as "it's down," both for your stress levels and for measuring how long the outage lasted.
- Don't cry wolf. If a monitor false-alarms a few times, people mute the channel and the whole setup becomes decoration. Content matching and sensible timeouts do most of the work here.
Step 5: Consider a public status page
When something does go wrong, a public status page turns a support avalanche into a link. Users check it, see you already know, and wait. It also builds trust the rest of the time: months of visible 99.9%+ uptime is quiet social proof that you take reliability seriously.
Watch the response times, not just the red and green
Once monitoring runs for a few weeks, the response time graph becomes an early-warning system. A site that used to answer in 300ms and now takes 900ms isn't down — but it's telling you something: a database growing past its indexes, a server running out of memory, a slow deploy. Downtime is usually the last chapter of a story that response times started telling weeks earlier.
Setting this up with DeadBro
Uptime monitoring is built into DeadBro — we call it Is It Dead — and it works for any website, whether or not the rest of your stack is Rails. Checks run every 1 or 5 minutes and support all the HTTP methods plus FTP and SFTP, with custom request headers and string matching for exactly the "200 but broken" problem above. Alerts go to Slack or email, every check gets an uptime percentage and response time history, and you can flip on a public status page per check. The free tier includes uptime checks with no card required — and if you do run Rails, your uptime data sits in the same dashboard as your request traces, slow queries, and errors, so "the site is down" and "here's why" are one click apart.
The ten-minute payoff
Uptime monitoring is one of the rare things in infrastructure with an instant return: ten minutes of setup, and you'll never again learn about an outage from a customer. Start with your homepage and your most important page, add a content match, point the alerts at Slack, and let the response time graph quietly collect evidence in the background.
The worst time to set up uptime monitoring is right after you needed it.