SSL Certificate Expiration Monitoring

A certificate that expires on a weekend is a common and avoidable kind of outage. The website is running, but browsers refuse to open it. This page describes what to do when UptimeWire warns you, and what the warning can and cannot do for you.

For how certificates work and why renewal fails, read the guide How to Prevent SSL Certificate Expiration. This page starts where that guide ends: a warning is in your inbox.

What an expired certificate looks like to visitors

When the certificate has expired, browsers show a full-page warning and many visitors leave. The server may be perfectly healthy. That is why an ordinary availability check can pass while visitors are blocked, and why the certificate needs a check of its own.

The workflow

1. Monitor an https address

Each website you add has its certificate checked, as long as the address starts with https://. The check reads the certificate the server presents for that address.

2. Choose the warning period

The warning period is set for each website. You can choose 1, 2, 3, 7, 14, 30, or 60 days before expiry.

A longer period gives more room if renewal needs someone who is away, or an approval. A shorter period fits a certificate that renews automatically and that you only want to hear about when something has gone wrong. If you are unsure, 14 or 30 days leaves time to react without being a constant reminder.

3. Receive the warning

The warning is sent by email and by Telegram. Other channels, such as Slack or Discord, do not carry certificate warnings, so keep email on for this.

The certificate check runs about every six hours. A warning therefore arrives some hours after the threshold is crossed, not at that exact moment. Treat the chosen period as a lead time, not a deadline.

4. Inspect the certificate

Open the website and look at the certificate details. Note the expiry date, the name it was issued for, and who issued it. If the date is later than the warning suggests, the renewal may already have happened while the server is still serving the old file or has not been reloaded.

5. Renew and deploy

This part happens in your own infrastructure. Depending on your setup it may mean running the renewal tool, asking the provider, or uploading a new certificate. UptimeWire has no part in it.

6. Verify what is being served

Renewing is not the same as serving. Many servers keep using the old certificate until they reload. Open the address again and check the new expiry date. The next scheduled check of the certificate also updates what UptimeWire shows.

A worked example

This is an invented example, not a customer case. A freelancer looks after a small business website. They set the warning period for https://example.com/ to 14 days. The certificate renews automatically, but a change to the server settings has stopped the renewal from working.

Fourteen days before the expiry date, a warning arrives by email. The freelancer opens the website and sees the old certificate. They run the renewal tool, find the error, fix the setting, reload the server, and check that the new date appears.

Without the warning, the first sign would have been a visitor, or a browser message on the day the certificate ran out.

What this does not do

• It does not renew certificates. Automatic renewal is a separate process in your hosting.
• It does not cover every certificate you own. Monitoring https://example.com/ checks the certificate that address serves. Other websites, subdomains, mail servers, and internal services need their own entries or other tools.
• It does not give an exact-moment alert. Certificates are checked about every six hours.
• It does not find the cause of a failed renewal. It tells you that expiry is approaching.

When this fits

This workflow suits anyone who relies on an https website and does not want certificate expiry to be a surprise, whether the certificate is renewed by hand or automatically. The more automatic your renewal is, the more a warning acts as a safety net for the day the automation fails.