Monitor more than the homepage. A complete setup covers the homepage, every conversion path (login, signup, checkout and search), the API endpoints your apps depend on, payment callbacks and webhooks, scheduled jobs, SSL certificates, domain registration, DNS records including MX, the servers underneath and the third-party services you rely on. A small business site needs a handful of checks; a store or SaaS product needs a few dozen. Start with what earns money, then add what can expire or fail silently. For the bigger picture, read how reliable uptime monitoring helps your website perform.
This checklist goes through each item, explains what to check and why, and ends with example setups for a small site, an online store, a SaaS product and an agency, plus a naming convention that keeps it all readable.
1. The homepage
The homepage is the obvious first monitor, and a good one: if it is down, everything is down. But it is often served from a CDN or page cache, so it can stay up while the application behind it fails. Monitor it with an HTTP(S) check every minute and validate a piece of stable content, such as the company name in the footer, so a cached error page does not count as up. Then move on to the pages that tell you more.
2. Conversion paths
These are the pages that earn money or keep customers, and they depend on the database, sessions and application code that the homepage may skip:
- Login: proves sessions and the user database work. Monitor the login page and validate that the form is there.
- Signup or registration: the start of every new customer.
- Cart and checkout: for a store, the most important pages on the site. Monitor the checkout page itself, not just the product pages.
- Search: often powered by a separate service, so it fails on its own. Monitor a search results URL with a query that always returns results, and validate that a result appears.
- Booking or contact forms, if that is how leads arrive.
Check these every minute. For most businesses, a broken checkout costs more per minute than anything else on this list. Uptimecheck uptime monitoring supports custom methods, headers, basic auth and response validation, so you can check that checkout works, not only that it loads.
3. API endpoints
If you have a mobile app, a single-page frontend or partner integrations, the API is the product. Monitor:
- A health endpoint that checks the database, cache and disk. See how to build a health check endpoint.
- The main read endpoint, with the API key header your clients send.
- One write endpoint, with a safe test payload, if writes are critical.
Validate the response body, not just the status code: an API that returns 200 with an error message is still down. API monitoring and the API monitoring checklist go deeper.
4. Payment callbacks and webhooks
Payment providers, shipping services and other platforms call your site back to confirm orders and update status. If the receiving endpoint breaks, payments may succeed while orders are never marked as paid. Nobody sees an error page, because no visitor is involved.
You usually cannot send a real callback from a monitor, but you can check that the endpoint answers. Many webhook receivers return a 4xx code for a request without a valid signature; if that is the expected response, monitor for it. A 5xx or a timeout then means the receiver itself is broken. Pair it with the provider’s own delivery logs, which show failed callbacks from their side.
5. Cron jobs and background work
Backups, imports, invoice runs, feed exports, newsletter sends and queue workers do not have a URL to check. They fail silently. Give each one a heartbeat: the job requests a unique URL when it finishes, and an alert goes out when the request does not arrive on time. Uptimecheck plans count heartbeats separately from monitors, so this does not eat into your website checks.
6. SSL certificates
An expired certificate shows every visitor a full-page browser warning and breaks API clients outright. Monitor the certificate on every hostname you serve, including www, the API subdomain, the status page domain and admin panels, and get reminders weeks before expiry. Automatic renewal makes expiry rarer, not impossible. See SSL certificate expiry monitoring for the common failure modes.
7. Domain registration
When a domain registration lapses, the website, email and API on it all stop at once. Registrar reminders often go to an old address. Track the expiry date of every domain you own, including country variants, campaign domains and old brand names that still redirect.
8. DNS records, including MX
DNS decides where traffic and email go. Watch for changes to:
- A and AAAA: where the site loads from.
- NS: who controls the zone. A change here is always worth a look.
- MX: who receives your email, including order confirmations and password resets.
- TXT: SPF, DKIM and DMARC. A removed record can send your email straight to spam.
- CNAME and CAA: CDN aliases and which certificate authorities may issue for the domain.
An unexpected change is either a mistake or an attack. DNS monitoring alerts you with the old and new value. If you run your own mail server, add a port check on it as well, for example SMTP on port 465.
9. Servers
If you run your own servers or VPSs, monitor CPU, load, memory, swap, disk, network and reboots. These catch the causes of outages before they become symptoms: a disk that will be full on Thursday, a memory leak, a reboot after which a service did not start. Server monitoring sits next to your uptime checks, so the cause and the symptom appear on the same screen. On fully managed hosting, you can often skip this and rely on the provider.
10. Third-party dependencies
Your site depends on services you do not run: payment providers, email delivery, search, a headless CMS, an authentication provider, a CDN. When one fails, your site may load while the feature behind it is broken. Monitor the public endpoints you rely on, or your own endpoints that exercise them, so you can tell a customer within minutes whether the problem is yours or upstream. Keep these on a lower-priority alert channel, since you cannot fix them yourself.
How many monitors do you need?
The setups below are examples to adapt, not fixed recipes:
| Type of site | Example setup |
|---|---|
| Small business site, such as fjordstudio.se | Homepage, contact form page, SSL, domain, DNS for A and MX, one heartbeat for the backup. Around 3 HTTP monitors plus the expiry and DNS checks. |
| Online store, such as northwind.shop | Homepage, a category page, product page, cart, checkout, login, search, payment callback, health endpoint, SSL on every hostname, domain, DNS, heartbeats for backups, feed exports and order syncs, and the servers. Roughly 10 to 15 HTTP monitors. |
| SaaS product, such as lumenanalytics.io | Marketing site, app login, signup, API health, main API endpoints, webhook receiver, status page, SSL, domains, DNS, heartbeats for every worker and scheduled job, and servers. Often 15 to 40 monitors. |
| Agency | The small-site set for every client, plus checkout and login for client stores, grouped per client. Usually a few monitors per client, multiplied by the number of clients. |
Begin with the conversion paths and expiry checks, run for two weeks, then add what you wished you had during the first incident.
Naming conventions
A monitor name is the first thing someone reads in an alert at night. Make it answer “what broke, where, and how bad” without opening anything:
[client or product] – [environment] – [what] – [check type]
Northwind – prod – Checkout – HTTPS
Northwind – prod – Payment callback – HTTPS
Northwind – prod – Nightly backup – heartbeat
Lumen – prod – API health – HTTPS
Lumen – staging – API health – HTTPS
Fjord Studio – prod – MX record – DNS- Use the same order everywhere, so alerts can be scanned and sorted.
- Name things the way the team talks about them, not by internal hostnames.
- Mark environments clearly, so a staging alert never looks like production.
- For agencies, start with the client name and group monitors per client in projects, so each client’s monitors and alerts stay together.
The checklist
- Homepage, with content validation.
- Login, signup, checkout and search.
- API health and main endpoints.
- Payment callbacks and webhook receivers.
- A heartbeat for every scheduled job that matters.
- SSL on every hostname and every domain’s registration.
- DNS records: A, AAAA, NS, MX and TXT at least.
- Servers, if you run your own.
- Key third-party services, on a lower-priority channel.
- Clear names, and alerts routed to whoever owns each item.
Uptimecheck covers websites, APIs, heartbeats, SSL, domains, DNS and servers in one account. Start a 14-day free trial, no credit card required.