What Should You Monitor? A Practical Checklist for Websites and Services.

"Monitor the website" sounds like one task. In practice a site depends on a chain of things - DNS, a certificate, a web server, an API, a database, background jobs - and any link can break while the homepage still looks fine. This checklist helps you decide what to watch, in what order, and how often.

Key takeaways

• Start with what users touch: the homepage, login, checkout and your public API.
• Add the dependencies that fail silently: SSL certificates, domain registration, DNS and cron jobs.
• Check infrastructure (ping and ports) for servers that don't serve web pages.
• Match the check interval to the cost of downtime, not to habit.
• Every monitor needs an owner and an alert channel someone actually reads.

Start with the user journey

List the few pages and actions that, if broken, would make customers call you. For most businesses that is:

• The homepage - the first thing people and search engines see.
• Login or sign-up - often a separate service with its own failure modes.
• The money path - product page, cart, checkout or payment callback.
• Your public API - if partners or a mobile app depend on it.

For each of these, a plain HTTP check that expects a 200 is a start. Better is a keyword check that looks for a word that only appears when the page really works, such as the product name or "Sign out". Error pages frequently return 200 too.

Add the silent failures

Some problems never show up as a slow page - things just stop one day.

SSL certificates

An expired certificate makes browsers show a full-page warning. Monitor the expiry date and get warned two to four weeks ahead, which leaves time even when renewal is manual. See SSL monitoring.

Domain registration

A lapsed domain takes the website, email and every subdomain down at once, and recovering it can be slow. A domain-expiry monitor costs nothing and prevents an embarrassing outage.

DNS

DNS changes, expired nameserver delegations or a misconfigured record can send visitors elsewhere. A DNS monitor that compares answers with what you expect catches it.

Scheduled jobs

Backups, invoice runs and data syncs fail quietly. Use heartbeat monitoring: the job pings a URL when it finishes, and you are alerted when the ping doesn't arrive.

Cover the infrastructure

Not every server serves web pages. Mail servers, databases, VPN gateways and internal tools still need watching:

A port check only proves the service accepts connections, not that it works correctly - combine it with an application-level check where you can.

How often should you check?

Pick the interval from the cost of not knowing:

Faster checks find problems sooner, but alerts still need confirmation. Checking from several locations and only alerting when more than one sees the failure removes most false alarms caused by a single network path.

Decide who gets told

A monitor nobody reads is decoration. For each monitor decide:

1. Who owns it - a person or team, not "everyone".
2. How they hear about it - SMS for urgent, Telegram or Bale for the team channel.
3. What happens if they don't respond - an escalation to a second person after a few minutes.

Keep low-urgency monitors (a slow marketing page) away from the phones that wake people up at night.

A starter set

If you are starting from nothing, this set covers most small and medium sites in under fifteen minutes:

1. HTTP or keyword check on the homepage, every 1-5 minutes.
2. Keyword check on login and checkout.
3. SSL expiry and domain expiry for the main domain.
4. Ping on each server, port checks on mail and SSH.
5. A heartbeat monitor on the nightly backup.
6. A status page that shows the user-facing monitors.

Frequently asked questions

• Is monitoring the homepage enough?

  +

  No. The homepage is often cached or served by a CDN and keeps working while login, checkout or the API is broken. Monitor the paths users take to do something.

• Should I monitor third-party services?

  +

  Monitor the ones your core flow depends on - payment gateways, SMS providers, maps. You can't fix them, but knowing early lets you switch providers or tell users what's happening.

• How many monitors do I need?

  +

  Usually between five and twenty for a typical business site. Start with the starter set above and add a monitor every time an incident teaches you about a new failure.