The Expiry Dates That Take Websites Down

An uptime monitor watches for the site going down. It is very good at that. What it cannot do, by design, is warn you about the two failures that are scheduled months in advance and arrive without any warning signs at all.

An SSL certificate that expires at midnight produces perfect 200 responses right up until the moment every browser starts refusing to load the site. A domain registration that lapses does the same, except worse. The DNS records disappear, and as far as the internet is concerned the site no longer exists.

Both are entirely preventable, and both keep happening to competent teams.

Why these two are different

Almost every outage has a build-up. Response times creep, error rates climb, a deploy goes out, a disk fills. Even the sudden ones leave a trail of failed requests you can look at afterwards.

Expiry has none of that. There is a date. On one side of it everything works and on the other side nothing does. Monitoring that only looks at HTTP responses will tell you about it precisely zero seconds in advance.

The failure is also unusually total. A broken deploy takes down a feature. An expired certificate takes down the whole domain for every visitor simultaneously, and greets each of them with a full-page browser security warning that says, in effect, that your site is dangerous.

Automatic renewal breaks quietly

The usual objection is that certificates renew themselves now. Mostly true, and it has moved the failure from "somebody forgot" to "the automation broke quietly." That happens less often, and when it does the outcome is exactly the same.

Renewal automation fails in ordinary ways:

• The ACME challenge cannot complete because a redirect rule now catches /.well-known/.
• The renewal succeeded but the service was never reloaded, so the old certificate is still in memory.
• The certificate renewed on the origin, and the CDN or load balancer in front of it is still serving the previous one.
• The cron job that runs the renewal has been failing since a server migration, and its output goes to an inbox nobody reads.
• The domain moved to a new provider and the automation stayed pointed at the old one.

Every one of those leaves you with a valid renewal process and an expiring certificate. The only reliable check looks at the certificate a visitor is actually served, from outside your network, and compares its expiry date to today.

Domains are worse

Certificates renew every 90 days, so the machinery gets exercised constantly and breakage surfaces quickly. Domains renew every one to ten years, which means the process is almost never tested and every assumption around it has had years to rot.

The card on file expired. The registrar account belongs to a contractor who left in 2023. The renewal notices go to an alias that now bounces. Nobody notices any of this until the domain enters its redemption period and reclaiming it costs a few hundred dollars and a week of frantic emails.

What good expiry monitoring looks like

The requirements are modest, which is what makes it frustrating that this so often goes unwatched.

Check from outside. The certificate that matters is the one a visitor's browser is handed at the edge. The file on your origin server can be perfectly fresh while a CDN in front of it serves last quarter's.

Warn more than once. A single warning email can be missed, deleted, or arrive while someone is on holiday. Barkme warns at 30, 14, 7, and 1 day before expiry, for both the SSL certificate and the domain registration.

Fire each threshold once. Warning daily for a month is how expiry alerts get filtered into a folder nobody opens. Each of those four thresholds fires exactly once.

Cover the whole domain. Barkme checks every verified domain once a day, so adding a domain covers it whether or not you have a monitor pointed at a particular page.

Send it where people already look. Expiry alerts go to your email, Slack, Telegram and webhook channels. Linear and Trello handle incidents only. An expiry warning is a calendar problem, and those boards are for things that are broken right now.

Reputation belongs in the same category

There is a third silent failure with the same shape. Your domain can land on a DNS filtering list or an email blacklist without a single failed request. The site is up, it responds normally to your monitor, and a growing share of visitors quietly cannot reach it because their resolver has decided it is malicious. Meanwhile your email lands in spam folders.

Barkme checks every verified domain daily on two independent tracks. Web reputation compares the DNS answer your domain gets from security-filtering resolvers against clean ones, catching the moment filters start blocking visitors. Mail reputation looks the domain up on Spamhaus DBL, SURBL and URIBL. You get one alert when a domain lands on a list, naming the sources, and one when it clears.

Inconclusive lookups are never reported as listings, which matters more than it sounds. A reputation checker that cries wolf on a timeout is worse than no checker at all.

What happens when a domain is blacklisted, and how to get off the list, is a post of its own.

Setting this up

The whole thing takes about five minutes.

1. Add your domain and verify it with a TXT record on the apex, host @, value barkme-verify= followed by the token shown to you. DNS propagation usually takes a couple of minutes.
2. Verifying an apex covers every subdomain and every URL beneath it, so you do this once per domain.
3. SSL and domain-expiry alerts are on by default, and each can be toggled per domain.
4. Confirm which channel they reach, and make sure at least one is somewhere a human looks daily.

Verification exists so that you can only monitor domains you own or operate, which is also what makes daily checks against blacklists and certificate authorities reasonable to run on your behalf.

The unglamorous point

Certificate and domain expiry are boring problems. There is no clever architecture to discuss and no war story worth retelling. They are calendar entries with catastrophic consequences, and the whole solution is something that reads the calendar for you and is stubborn about telling you.

Set it up once. Then go back to worrying about things that are genuinely hard.

Next: how often you should check your site is up, and why most uptime alerts are noise. If you want the background, how SSL actually works and how DNS works are both here too. The full pipeline is described in how Barkme works.