Renew the certificate before your visitors see the warning

Public TLS certificates used to last a year. Since 15 March 2026 the maximum is 200 days. It drops to 100 days in March 2027 and to 47 days in March 2029, under CA/Browser Forum Ballot SC-081v3.

Let's Encrypt moves faster. It plans 64-day certificates on its default profile from February 2027 and 45-day certificates from February 2028. More renewals means more chances for one to fail quietly: a changed DNS record, a firewall rule that blocks the validation request, a renewal timer that stopped with the old server.

The safety net is gone too. Let's Encrypt ended its expiry reminder emails on 4 June 2025. If your renewal breaks today, the first notice is often a browser warning in front of a customer.

Run this against your own hostname. The first command prints the date the served certificate expires. The second exits with status 1 when the certificate expires within 14 days, so a script can act on it.

Pass -servername so the server returns the certificate for that hostname. Without it, a shared host can return a default certificate and you read the wrong date.

host=example.com

echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null |
  openssl x509 -noout -enddate
# notAfter=Nov 19 21:58:47 2026 GMT

echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null |
  openssl x509 -noout -checkend $((14 * 86400))
# Certificate will not expire

A manual check works once. PostDeploy runs it every day at 00:10 UTC for each active HTTP and keyword monitor. It reads the certificate that the monitored HTTPS URL serves, and it looks up the domain's registration expiry.

You get a warning when the certificate or the domain is 14, 7 and 1 days from expiry. Each warning goes out once per threshold, to Email, Slack, Discord, Telegram or a webhook.

There is nothing extra to buy or count. Expiry warnings ride on the uptime monitor you already have, so the same check that tells you the site is down also tells you it is about to be.

First, add an HTTP monitor for the HTTPS address users visit. Ask a connected MCP client, for example: "Add an uptime monitor for https://example.com in my production project."

Then open Notification settings in the PostDeploy console. Add an alert rule for the Monitor trigger "SSL certificate expiring" and one for "Domain expiring". Point each rule at the channel you read.

Warning: an expiry warning is sent only through an enabled rule for that trigger. A project with only a "Check down" rule records nothing for an expiring certificate.

An automated certificate should never get close to 14 days. Let's Encrypt recommends renewal at about two thirds of the lifetime, which is day 60 for a 90-day certificate. When the 14-day warning arrives, automatic renewal has already failed for weeks.

Treat the first warning as a broken renewal, not a reminder. Run your ACME client's renewal by hand, read its error, and fix the cause: DNS, the validation path, or a stopped timer. Then run the openssl command above to confirm the new date.

Domain registration is different. Many registrars renew automatically but fail on an expired payment card. A domain warning usually means a billing problem at the registrar.

The scan runs once a day from one AWS region. It reads the certificate that this region receives. A CDN that serves different certificates in different regions can show a different date elsewhere.

Domain expiry comes from the public WHOIS record. Some registries, including many country-code domains, do not publish an expiry date there. For those domains PostDeploy sends no domain warning, and the certificate warning still works.