A certificate expiry monitor does one job. It reads the expiry date of the certificate your site presents and tells you before that date arrives. For a small team, the useful part is not the check itself. It is the warning schedule, the people who receive the alert and the steps they follow when it fires. This post covers those three things.
How a certificate expiry catches small teams out: renewals that quietly stop working
Most certificates are renewed by a process that someone set up months or years ago. It might be a scheduled job on a server, a hosting panel setting or a manual task in a calendar. When it works, nobody thinks about it. When it stops working, nothing announces that. The renewal fails, the old certificate carries on for a while, and then one day it expires.
Solo developers and freelancers feel this most. The person who set up the site is often the only person who knows where the renewal lives. If that person has moved on to another client, or is on holiday, the first sign of trouble may be a visitor's browser warning or a client asking why the checkout page looks broken.
A monitor gives you a dated signal that does not depend on anyone remembering. It turns a quiet failure into a message with a deadline attached.
What a certificate expiry monitor checks and what it does not
In AperioFlow, a certificate check looks at the site you add and reads the expiry date from the certificate it presents. It then compares that date with today and flags the result as the date gets closer. You add the site address, the check runs on a schedule and the expiry date is shown against that monitor.
It is worth being clear about the limits. The check reports what the certificate says. It does not renew the certificate for you. It does not confirm that your renewal process will work next time, and it does not check every service on your domain, such as mail servers or internal tools that you have not added. If a site sits behind a different address from the one you monitor, the check will only see what is served at the address you entered.
So treat the monitor as the thing that tells you a renewal needs attention. The renewal itself still belongs to your process, and you still need to test it.
Choosing warning points, for example 30, 14 and 7 days before expiry
A single warning, one week before expiry, is too late for many teams. A renewal can need a DNS change, a verification step from the certificate provider, or a wait for someone with access to the hosting account. A week may be enough for a simple renewal and not enough for a slow one.
A three-step schedule works well for most small teams:
- 30 days before expiry. This is the planning warning. Someone checks that the renewal method still works and that they have the access they need.
- 14 days before expiry. This is the chasing warning. If the renewal has not happened, it is now a task with an owner and a due date.
- 7 days before expiry. This is the urgent warning. Anything still open at this point needs to be treated as an incident, not a reminder.
You can change these points to suit your work. A team that renews by hand may want an earlier first warning. A team with automated renewals may only need the 7-day alert as a safety net. The important thing is that each warning has a different expected action, so the alert does not become background noise.
Who should receive the alert: people in your organisation, not just one inbox
The most common routing mistake is sending the alert to one person's address. That person may be busy, away or no longer responsible for the site. A certificate warning that reaches one inbox is only as reliable as that inbox.
In AperioFlow, alert emails go only to people in your organisation. That is a useful limit: the alert stays inside the team that runs the site, and you choose who in that team should see it. For a solo developer, this may be just you, with a second address for a backup contact. For a small agency, it may be the account lead for the client, plus the developer who usually handles renewals.
A simple rule works well. Name one primary owner for each site and one backup. Put both on the monitor's alerts. If the primary owner is unavailable at the 14-day warning, the backup already knows the renewal is due. Write the owners down in the same place as the site details, so the next person who picks up the work can find them without asking around.
What to do when the alert arrives: a short renewal checklist
An alert is only useful if the person who receives it knows what to do next. Keep a short checklist with each site, and let it be the first thing the owner opens.
- Confirm the expiry date on the monitor, and note which address the certificate was checked against.
- Find the renewal method. Is it an automatic renewal, a hosting panel setting or a manual request to a certificate provider?
- Check that the method still has access. Look at the account login, the DNS record or the email address the provider uses to verify ownership.
- Run the renewal now, rather than waiting for the next warning. Note the time and the person who did it.
- Check the result by looking at the expiry date on the monitor after the renewal has been applied. Allow time for the site to pick up the new certificate.
- If the renewal fails, tell the people who depend on the site, and record what you tried. A short incident note is enough.
- Update the checklist if something was missing, such as an expired login or a renewal address nobody could find.
Keep the checklist short enough to read in a minute. The aim is that a tired person at the 7-day warning can still follow it.
Pairing it with a website uptime monitor so you see the symptom as well as the cause
A certificate monitor shows you the cause before it becomes a problem. A website uptime monitor shows you the symptom if something has already gone wrong. Use both for the same site.
The certificate check tells you that a renewal needs attention. The uptime check tells you whether visitors can reach the site at all. If a certificate expires and an uptime check fails at the same time, you know the expired certificate is the likely cause and can move straight to the checklist. If the uptime check fails without a certificate warning, you know to look elsewhere.
This pairing also helps when you tell customers what is happening. You can point to the certificate as the reason, once you have confirmed it, and say what you are doing about it. For clients who run their own work through a status page, the monitor history gives you a factual record of when the problem started.
Start with one site
You do not need to set up every site at once. Pick the one that would cause the most trouble if its certificate lapsed. Add it with a certificate check, set the warning points you want, name a primary owner and a backup, and write the checklist down beside it. Then repeat for the next site.
The free plan includes 10 monitors, so you can cover your most important sites before deciding whether you need more. Start free at https://app.aperioflow.co.uk/#/signup
AperioFlow is hosted in France and run from the UK. You can download your data at any time if you decide it is not right for your team. Tweed Tyne runs its own work on it, which is one of the reasons we keep the certificate checks simple and the alert routing clear.