The problem: you hear first only when the client is angry
Most freelancers find out a client site is down from the client. The message usually arrives by phone or text, sometimes after a customer has already complained. By then the site may have been broken for hours, and you are working out what happened while the client waits.
Checking by hand does not fix this. You can open a site every morning, but that tells you about one moment. A shop can fail at 11 pm on a Friday, a form can stop sending on a Sunday, and a plugin update can break a page while you are asleep. If you manage six or twenty sites, the checking alone takes time you would rather spend on paid work.
A monitor does the looking for you. It requests a page on a schedule, notices when the page stops responding or returns an error, and sends an alert to the person who needs to act. You still decide what to do about it. You just hear about the problem first.
One monitor per client site, named clearly
Give every client site its own monitor. It is tempting to group several small sites under one monitor, but then an alert does not tell you which client is affected. Keep it simple: one site, one monitor.
Name each monitor so that anyone reading the alert knows the client and the site at a glance. A good pattern is the client name followed by the site purpose, for example 'Harbour Dental, booking page' or 'Lowry Prints, checkout'. A bad name is 'Site 3'. When you are on your phone at the end of a long day, a clear name saves you from opening the dashboard just to work out which job matters.
The free plan includes 10 monitors. That covers a handful of client sites with room to spare, so you can test the setup on your own sites or your most important client before you commit to anything else. If you work with a small team, the Team plan is 29 pounds a month flat for up to 10 people, as shown on the pricing page.
What to check on a typical brochure or shop site
A brochure site and a shop site fail in different ways, so the checks should differ too.
For a brochure site, the main question is whether the home page loads and whether the contact page is reachable. A contact form that fails silently is a common problem, because the site looks fine while enquiries disappear. If you can, add a check on the contact page as well as the home page.
For a shop, check the pages a customer needs to buy something: the product listing, the basket and the checkout. A checkout that returns an error is far more costly than a blog page that is slow. Put the checkout first in your mind when you decide which alerts matter most.
Do not alert on everything. If every small slowdown sends a message, the client will learn to ignore your alerts, and then the real one gets missed. Decide what counts as a problem worth waking up for, and what can wait until the next working day.
Certificate expiry per domain
An expired security certificate makes a site show a warning page to every visitor. Many people leave at that point, and the client often blames the designer. Certificates expire on a fixed date, so this is one of the easiest problems to prevent.
Keep a record of the expiry date for every domain you look after. Record it beside the client name, not in a separate file you will forget. Give each domain its own line, so a renewal is never tied to a different client's date. Check the list at the start of each month, and set a reminder a few weeks before each date. If a certificate is managed by the hosting company, note who renews it, because a renewal you assumed was automatic is a common source of surprise.
Who receives the alert (people in your organisation only)
Decide who gets each alert before anything breaks. Alert emails go only to people in your organisation. For a solo freelancer, that is you. If you have a small team, add the people who actually act on the site, such as the developer on call or the person who handles client support.
Do not forward alerts to clients by default. A client who receives every raw notification will start to worry about small blips. Instead, you decide when a client needs to hear something, and you write that message yourself. That keeps the client informed without flooding them, and it keeps the decision with the person who understands the problem.
If you change who looks after a site, update the alert recipients on the same day. An alert that goes to someone who left the project last spring is no alert at all.
Telling a client what happened, in plain words
When a site goes down, the client wants three things: whether it is fixed, whether they lost anything, and what happens next. Answer those in the first message, before you explain the technical detail.
A short update might read: 'The booking page on your site was unavailable from about 9.40 this morning. The cause was a plugin update. It is fixed as of 10.15, and bookings made during the outage will be recovered from the form log today. I will check the page again this afternoon and confirm.' That is enough. It names the problem, gives the times, says what changed, and tells the client what you will do next.
Avoid jargon, and avoid blaming anyone. Do not write 'the server threw a 502' unless the client asked. Do not promise that it will never happen again, because you cannot guarantee that. Say what you have changed to make a repeat less likely, and leave it there.
Keep a note of each incident, with the times and the fix. Over a year, those notes show you which sites cause the most trouble and which fixes stuck. They are also useful when a client asks what they are paying for.
Keeping a short list of sites and their owners
The hardest part of looking after many sites is often not the monitoring. It is remembering who owns each site, who pays for hosting, and who to ask about the login. Keep a single short list that holds, for each site: the client name, the domain, the monitor name, the certificate expiry date, the hosting provider, the person who renews the domain, and the person to contact about changes.
Keep the list short. If it runs to pages, nobody will read it. One line per site is enough for most freelancers. Review it every month, at the same time you check certificate dates, so the two stay in step.
If you want to see how this works in practice, Tweed Tyne runs its own work on AperioFlow, so the routine described here is one we use ourselves. AperioFlow is run from the UK and hosted in France. You can download your data at any time if you decide to move on.
Start free at https://app.aperioflow.co.uk/#/signup and add your first client site in a few minutes. Begin with the site that would cost you the most if it went down, and build from there.