Most agencies monitor whether the site is up. Fewer monitor the three things that decide whether it will be up next month: the SSL certificate, the domain registration and the DNS records. These fail rarely, fail completely, and always fail on a day when the client is trying to sell something. They are also the outages that are hardest to explain to a client, because the answer is "nobody was watching the renewal date."
Why these are different from ordinary downtime
A server outage is noisy. Uptime checks fire, someone gets paged, and the cause is visible in logs. Expiry failures are the opposite. Nothing is wrong on Monday, and on Tuesday everything is, with no gradual degradation in between.
They also sit in a gap of ownership. The hosting company handles the server, the registrar handles the domain, a DNS provider handles records, and the certificate is issued by yet another party, often automatically. Each renewal depends on a card on file, an email inbox or a cron job that someone set up once and forgot. Every one of those is a single point of failure that nobody is assigned to.
SSL expiry
Certificates from automated issuers renew on a schedule, and most of the time that works. The failures come from the edges. The renewal job breaks after a hosting migration or a server rebuild. A firewall or redirect rule blocks the validation request. A certificate was bought manually years ago, and the reminder went to a former employee's mailbox. Someone changed DNS and the validation record disappeared.
When one expires, browsers show a full-page security warning. Visitors do not click through that; they leave, and many assume the business has been hacked. For the client that is worse than a slow site, because it looks like a trust failure.
What to do: check the expiry date for every site's certificate at least weekly, and alert well before the date, not on it. A threshold of 14 days gives you time to fix a broken renewal job and time to retry if the first fix fails. Also confirm which certificates renew automatically and which do not. The manual ones are your real risk list.
Domain expiry
Domains are the most severe of the three. An expired domain stops the website, and it also stops email, which is often the thing the client notices first. After a grace period, it can go to public auction, and people watch for lapsed business domains.
The usual causes are mundane. The domain sits in the client's own registrar account, on an old card. Or it is registered under a former web designer's account, and the client does not know. Auto-renew was switched off years ago, or the registrant email is an address that no longer exists.
The agency-level fix is administrative. Keep a list of every client domain with its registrar, registrant contact, expiry date and auto-renew status. Where you can, move domains into an account you control and bill for them, because a paid renewal you manage is an asset you can guarantee, and an unmanaged one is a liability you inherit.
Do the arithmetic on why it is worth the effort. A domain costs the client a modest annual fee. Recovering one after it lapses can mean days of downtime, lost email and possibly a purchase back from a third party. The renewal is trivial, the failure is not.
DNS drift
DNS drift is the slowest of the three. Records change over time: someone adds a marketing platform, an email provider is swapped, a subdomain is pointed at a service that is later cancelled. Each change is reasonable in isolation. Together they leave records that no longer match reality.
Typical symptoms: email suddenly lands in spam because SPF or DKIM records no longer reflect the actual sending services. A subdomain still points to a decommissioned service, which can be claimed by someone else. The site works from your office and fails elsewhere because an old record is cached differently. Or a migration was done, but old records still send some traffic to the previous host.
Nobody sees drift until it hurts. The remedy is a snapshot: record the DNS for each client domain when you onboard the site and when you migrate, then compare periodically. Even a text file in your documentation will do, because the value is in being able to say "this is what it was on the last day it worked."
Watching the symptoms
You cannot monitor everything at the record level for every client, but you can catch the symptoms quickly. Uptime checks from more than one location are worth having for exactly this reason: an expired certificate or a DNS problem can show up as failures from some places and not others, and a single-location check can miss the pattern or report a false alarm. WPClientHub runs uptime checks every 60 seconds, which will tell you that something is wrong within a minute, though it will not replace a registrar reminder for the renewal date itself.
A one-page expiry register
If you do nothing else, build a register with one row per client and these columns:
- Domain and registrar.
- Domain expiry date and whether auto-renew is on.
- Certificate issuer, expiry date and whether it renews automatically.
- DNS provider and date of the last DNS snapshot.
- Who is the named owner of each renewal, and which payment method it uses.
Review it monthly, sorted by soonest expiry. It takes about as long as a coffee for a small portfolio and it removes an entire category of preventable emergencies. Put the domain and certificate dates in calendar reminders too, so that a lapse in one tool does not silently disable your only alert.
Where this leaves you
Treat expiry as a scheduled task with a named owner, not a background assumption. Keep a register, alert at least two weeks ahead, snapshot DNS, and make sure the domains are in accounts someone actually manages. WPClientHub can give you the fast uptime signal when one of these does slip, and it is free for 3 sites if you want to try this on a real client site: try it free.