Domain and SSL certificate renewals
What actually breaks
An expired certificate
Every visitor gets an interstitial warning telling them the connection isn’t private. Most of them leave. API clients and mobile apps fail outright rather than warning, so integrations break at the same moment. There is no grace period — it works, and then at a specific timestamp it doesn’t.
An expired domain
The site stops resolving and, more painfully, so does email — including the password-reset messages you would need to fix it. After expiry most registrars move a domain through a grace period and then a redemption period, where recovering it costs substantially more than the renewal would have. The exact windows vary by registrar and TLD; check your registrar’s published policy rather than assuming you have a month.
Why auto-renew is not the safety net people think
“It’s on auto-renew” is the reason most of these are not tracked, and it fails in four ordinary ways:
- The card expired. The single most common cause. The renewal attempt fails, and the failure notice goes to…
- …a mailbox nobody reads. The registrar account was set up with a role address, or a personal address belonging to someone who left.
- The domain is in a personal account. Registered years ago by a contractor or a founder, on their own login. Auto-renew is on, right up until their card changes.
- The certificate was never automated. Automatic issuance covers the common case; the wildcard someone generated by hand for an internal service does not renew itself, and nothing tells you until it fails.
What to track
| Domain names | Every domain you own, including the defensive registrations and the old brand nobody has redirected yet. |
| SSL / TLS certificates | Per hostname. Wildcards and multi-domain certificates expire as one date; a certificate you forgot renews nothing on its own. |
| Hosting and CDN plans | Usually annual, usually on someone’s card, usually invisible until it fails. |
| DNS and email routing | The service, not the records — if the DNS provider lapses, everything downstream goes with it. |
| Code signing and dev certificates | Expire quietly, then break installers and builds with an error nobody recognises. |
Record a named owner against each one. Not “IT” — a person. The failure mode here is never that nobody could have renewed it; it is that everybody assumed somebody else had.
Reminders timed to how these actually fail
SpendRegister runs the same escalating ladder on a certificate as on anything else: 3 months, 2 months, 1 month, 1 week and 1 day before the date. Then, if the date passes with no decision, it repeats weekly until a person resolves it — it does not give up and it does not mark itself done.
Three months matters more here than elsewhere. It is enough time to move a domain between registrars, to get a purchase order through finance, or to chase down whoever owns the account — none of which is possible with a week’s notice.
Keep them with everything else, not in a monitoring tool
Uptime monitors will tell you a certificate is close to expiry, and they are worth having. What they won’t do is tell a named person repeatedly until they act, hold the renewal price so you can see it climb, or sit in the same list as the contract renewals your finance lead is already looking at.
A domain, a subscription and a warranty are the same shape of problem: a date, an owner, and a decision. Splitting them across three systems is how one of the three ends up unowned. How the ladder works.
Put the certificate expiry somewhere it will chase someone
Free for up to 10 items — enough for your domains and certificates on its own, if that is where you want to start. No per-seat fees, so the whole engineering team can see the same dates.