Website monitoring checklist for freelancers

When a client's website breaks, they do not blame the host or the certificate authority. They call the person who built it. Monitoring is how you hear about the problem before they do.

This checklist covers what is worth watching on a typical client website, why each item matters and how often to check it. It is written for freelancers who look after several sites at once, so every item has a cheap, boring default.

What should I monitor on a client website?

Work from the failures clients actually notice, in this order:

Uptime and response time

Uptime monitoring means a service outside your network requests the page every few minutes and tells you when it fails.

• Monitor the homepage and at least one inner page. A homepage served from a cache can look fine while the application behind it is down.
• Confirm a failure before alerting. Good tools re-check from a second location, which keeps one network blip from waking you up.
• Watch response time, not only status. A page that answers with a success code in eight seconds is a failure in practice.
• Send alerts to two places, for example email and a chat app, so a single missed notification is not the end of the story.

SSL certificates

An expired certificate is the most avoidable outage there is, and it is getting more frequent to renew.

• Track the expiry date of every certificate, including subdomains such as a blog, a staging site or a shop.
• Do not trust auto-renewal blindly. It fails when a DNS record changes, a validation file is removed or a hosting plan is cancelled.
• Plan for shorter lifetimes. The industry has agreed to shorten the maximum lifetime of public certificates in stages, to 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. A calendar reminder once a year no longer works.

You can check any certificate yourself:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate

Our guide on how to track domain and SSL expiry dates covers the full process.

Domains and DNS

The domain is the one asset you cannot rebuild if it lapses.

• Record the expiry date and the registrar for every client domain.
• Confirm who owns the registrar account. If it is you, the client should still be able to recover it. If it is the client, make sure the renewal notice reaches an inbox someone reads.
• Check that auto-renew has a working payment method. An expired card is the most common reason an auto-renewed domain lapses.
• Note any DNS change. A record changed by someone else can break email or the site without a visible error.

Deploys and code

If you deploy through a host such as Netlify or Vercel, the site you see is only as current as the last successful build.

• Check that the most recent deploy succeeded, and separately which release is live. A failed attempt after a good release leaves the old version running, which hides the failure.
• Watch the CI status of the repository. A failing workflow is an early warning that the next deploy will not go out.

Key flows

An uptime check proves a page loads. It does not prove the site works.

• Test the flow that earns the client money, such as the contact form, a booking step or checkout.
• Use a keyword check for something that only appears when the page is healthy, such as the form's submit button.
• Submit the form yourself once a month and confirm the email arrives.

Search visibility and performance

Traffic problems rarely announce themselves.

• Open Search Console for each client at least monthly and compare clicks and impressions with the previous period. See how to view all your Search Console sites in one place.
• Run Lighthouse on the homepage after significant changes and keep the scores in a note. A drop right after a deploy points at what to look at first, although the deploy is timing, not proof of cause.

How do I set up alerts that do not become noise?

1. Send urgent alerts, such as downtime and certificates expiring within a few days, to a channel you will see on a phone.
2. Send slower items, such as a domain expiring in two months, to a weekly digest or a calendar entry.
3. Name the client in every alert, so you do not have to work out which site is affected.
4. Review the setup every quarter. Old alert contacts and removed sites are the most common gaps.

A simple routine

• Continuously: uptime, response time and SSL, handled by a tool.
• On every deploy: check that the build succeeded.
• Weekly: glance at everything that needs attention, ideally on one screen.
• Monthly: search visibility, performance and a test of the key flow.
• Quarterly: domain and hosting renewals, registrar ownership and alert contacts.

Where Datumboard fits

You can run this checklist with a mix of an uptime monitor, calendar reminders, Search Console and a spreadsheet. Datumboard is being built to put the same signals for every client site and side project on one screen, so the weekly glance takes a minute. It is in early access, and you can join the list below.