Website monitoring: What it is and why you need it

Your website is down. You don't know it yet.

A customer tries to visit, gets an error, and leaves. Then another. And another. An hour passes before someone finally emails you: "Hey, is your site working?"

By then, the damage is done.

This is why website monitoring exists - to make sure you find out about problems in minutes, not hours.

Table of contents

• What is website monitoring?
• How it works
• What can go wrong
• Setting up monitoring
• What to monitor
• Alerting that works

What is website monitoring?

Website monitoring is exactly what it sounds like: regularly checking that your website is working.

At its simplest, a monitoring service visits your site every few minutes and checks if it loads. If it doesn't, you get an alert.

But "working" can mean different things:

• Is it reachable? Can users get to it at all?
• Is it fast? Does it load in a reasonable time?
• Is it correct? Does it show the right content?

Good monitoring checks all three.

How it works

A monitoring service runs checks from servers around the world. Every 30 seconds (or whatever interval you set), it makes a request to your site and checks the response.

If your site returns a 200 status code and loads within your threshold, the check passes. If it returns an error, times out, or is missing expected content, the check fails.

When checks fail, you get notified. Most services let you configure multiple notification channels - email, Slack, SMS, phone calls - depending on how urgently you need to know.

The "from around the world" part matters. Your site might work perfectly from your office in London but be completely unreachable from Australia because of a CDN issue. Multi-region monitoring catches these problems.

What can go wrong

Websites go down for all sorts of reasons. Some common ones:

Server crashes - Your web server runs out of memory, hits 100% CPU, or just dies. The process stops, and requests go unanswered.

Deployment failures - You push a bad deploy. The new code crashes on startup, or has a bug that breaks the homepage.

SSL certificate expiry - Your certificate expires, and browsers refuse to load your site. Users see scary security warnings.

DNS issues - Your domain stops resolving. Maybe your registrar had an issue, maybe you forgot to renew, maybe someone misconfigured something.

Database problems - Your database runs out of connections, fills up its disk, or just becomes unreachable. Your app can't load data, so pages fail.

Third-party failures - A CDN, DNS provider, or cloud region goes down. Your code is fine, but users can't reach it.

Traffic spikes - You get featured on Hacker News or Reddit. Your server can't handle the load and starts dropping requests.

The frustrating thing is that many of these failures are silent. Your server might be happily serving errors while you have no idea anything's wrong.

Setting up monitoring

Here's how to get started with website monitoring:

1. Start with your homepage

Add your main URL. This is the most important page - if it's down, your whole site is effectively down.

2. Set a reasonable check interval

Every 30 seconds to 1 minute is good for most sites. Faster catches issues quicker but generates more traffic.

3. Choose your regions

Pick regions where your users actually are. If you're serving a US audience, check from US locations. If you're global, check from multiple continents.

4. Add content verification

Don't just check for a 200 status code. Add a text check to verify the page contains expected content.

For example, if your homepage always has "Welcome to Acme Corp", check for that text. This catches cases where your server returns 200 but serves an error page or blank content.

5. Set up alerts

Configure where notifications go. At minimum, email. For critical sites, also Slack and SMS.

6. Test it

Deliberately break something and verify you get an alert. You don't want to find out your alerting is broken during a real outage.

What to monitor

Start with the basics and expand from there:

Essential

• Homepage - Your main entry point
• Login/signup pages - Critical for user access
• Core product pages - Whatever your users actually use

Important

• API endpoints - If you have an API, monitor it separately
• Payment flows - Checkout pages, subscription management
• SSL certificate - Monitor expiry dates

Nice to have

• Marketing pages - Blog, docs, landing pages
• Third-party dependencies - Status pages of services you rely on
• Performance baselines - Alert if response time degrades significantly

You don't need to monitor everything. Focus on pages where downtime actually hurts your business.

Alerting that works

The point of monitoring is to get alerts when things break. But alerting is easy to get wrong.

Too many alerts and your team ignores them. Every alert becomes noise.

Too few alerts and you miss real problems.

Wrong channels and the right people don't see the alert in time.

Here's what I recommend:

For critical pages

• Check frequently (every 30 seconds)
• Alert immediately on failure
• Use aggressive channels: SMS, phone call, PagerDuty
• Multiple team members should receive alerts

For important pages

• Check every few minutes
• Allow 2-3 failures before alerting (to filter out blips)
• Use Slack or email
• Route to the relevant team

For everything else

• Check less frequently
• Higher failure threshold before alerting
• Email or a low-priority Slack channel

The key is matching the alert urgency to the business impact. Your marketing blog being slow for 5 minutes is not the same as your checkout being down.

I wrote more about this in saving your team from alert fatigue.

---

Website monitoring is one of those things that feels unnecessary until you need it.

The first time you catch an outage in 2 minutes instead of 2 hours, you'll wonder how you ever operated without it.

Start simple: one check on your homepage, alerts going to your email. You can always add more later.