← All articles
Guide

How to monitor your clients' websites (uptime, SSL and speed)

A simple guide for freelancers and small studios. What to watch on every client site (uptime, SSL, speed), how often, and how to get alerted before your client notices.

G
Gabriel Costa
Founder of Trrack.it · July 29, 2026 · 6 min read
Without monitoring17 hours unaware
Site goes downClient calls
With Trrack.it42 seconds
Site goes downAlert reaches you
The coloured stretch is the time the site is broken and you do not know it. Monitoring does not prevent the failure, it collapses that stretch from hours to seconds, which is the difference between you telling the client and the client telling you.

Every freelancer who builds websites for a living has lived this moment. You finish a project, hand it over, and move on to the next one. Three weeks later your phone buzzes with an angry message: "My site has been down since yesterday, why didn't you tell me?" You had no idea. You look bad, even though nothing about it was really your fault.

This is the freelancer monitoring gap. Your client assumes someone is watching their site, and since you built it, that someone is you. But nobody set anything up, so the first alert you get is the client's complaint. The good news: closing the gap takes about an afternoon, and once it is done you almost never think about it again.

Why this keeps happening

A finished website is not a static object. Certificates expire, servers hiccup, hosts have outages, a plugin update quietly breaks a page. None of these send you an email by default. So the site drifts along fine for weeks, then fails silently, and the only human who notices is a visitor or the client.

Three failures cause the overwhelming majority of these panicked calls:

  • Downtime. The server stops answering. The site is simply gone until someone reboots something.
  • An expired SSL certificate. The little padlock turns into a full-page browser warning that screams "Not secure" at every visitor. On an e-commerce site this stops sales instantly.
  • A slowdown. The site still loads, but it crawls. Pages that took under a second now take five, and visitors leave before they arrive.

Each of these is invisible to you unless something is actively checking for it.

What to actually watch

You do not need an enterprise observability stack. For client sites, three checks cover nearly everything that leads to an angry phone call.

1. Uptime

Have something request each site on a schedule and confirm it gets a healthy response. The key detail is frequency: a check every five minutes means you could be down for five minutes before anyone knows, while a check every minute means you know almost immediately. Just as important, a good monitor confirms a failure with a second check before alerting you, so one dropped request never becomes a false alarm at 3am.

2. SSL expiry

This is the easiest disaster to prevent and the most embarrassing to suffer. Certificates have a fixed expiry date, so there is no reason to ever be surprised by one. You want warnings well ahead of time, ideally at 14, 7, 3 and 1 day before expiry, with enough lead time to renew calmly instead of firefighting.

3. Response time

Set a threshold, for example three seconds, and get flagged when a site consistently crosses it. Slowdowns rarely take a site fully offline, so they hide from uptime checks, but they quietly cost your client traffic and conversions. Catching the drift early lets you raise it before the client does.

How to get alerted

A check is only useful if the alert reaches you where you already look. Email is the baseline. Slack or Discord is better if that is where your day happens, because the alert lands in the same place as the rest of your work. What matters is that you get told the moment a check fails, and again the moment the site recovers, so you are never left wondering whether the problem is still live.

One caution worth repeating: tune for signal, not noise. If a tool cries wolf with false positives, you will start ignoring it, and an ignored monitor is worse than no monitor. Confirming each failure before alerting is what keeps the signal trustworthy.

Setting it up without it becoming a project

The trap here is over-engineering. It is easy to spend a weekend wiring up a self-hosted monitor and a dashboard, and then spend more weekends keeping it alive. For a handful of client sites, that maintenance is not worth it.

The simple version looks like this:

  1. List every client site you are responsible for, even the ones you handed off long ago.
  2. Add each one to a monitor that checks uptime, SSL and response time together.
  3. Point alerts at your email and, if you use it, your team chat.
  4. Forget about it until something actually needs your attention.

The whole point is that a healthy site should be silent. You should only hear from the tool when there is something real to act on, and when that happens, you should hear about it before your client does.

The quiet business case

Closing this gap is not really about avoiding downtime, it is about how your clients perceive you. The freelancer who emails "heads up, your certificate renews in a week, I have it handled" looks like a professional who is still watching. The freelancer who goes silent until the client notices a broken site looks like someone who disappeared after the invoice cleared. Same work, very different reputation, and reputation is what brings referrals.

Monitoring costs less than a coffee per month and takes an afternoon to set up once. For something that quietly protects every client relationship you have, that is one of the highest-leverage afternoons in freelancing.

FAQ

How often should client sites be checked?

Every minute if the tool allows it, because the check interval is your worst-case blind time: a five-minute interval means a site can be down for five minutes before anything notices. What matters just as much is that a failure is confirmed by a second check before you are alerted, so one dropped request never wakes you at 3am for nothing.

Do I need monitoring for small client sites with little traffic?

Yes, and arguably more than for busy ones. A high-traffic site tells you it is down within minutes because someone complains. A small brochure site can be broken for a week before anyone notices, and the person who eventually notices is usually the client, which is the outcome monitoring exists to prevent.

What should I monitor besides whether the site loads?

Certificate expiry and response time. A site can return a perfectly healthy 200 while its certificate lapses tomorrow or while pages take five seconds to load, and neither shows up in a plain uptime check. Those three together, uptime, SSL and speed, cover almost every failure that ends in an angry phone call.

Should I tell clients I monitor their site?

It is one of the cheapest ways to look professional, so yes. A short line in your proposal, or a public status page they can check themselves, turns an invisible cost into something the client can see they are paying for. It also reframes the conversation when something does break: you are the person who already knows.

Is free uptime monitoring good enough?

For one or two sites, often yes. Free tiers usually cap the check interval, the number of monitors, or the alerting channels, which starts to hurt once you are responsible for a real portfolio. Judge a free plan on its check interval and on whether it covers SSL, because those are the two limits people hit first.


Trrack.it watches uptime, SSL and response time on all your client sites and alerts you before your client notices, at one flat price. Your first site is free, so you can see it in action in a couple of minutes.

Keep reading