SSL certificate monitoring with expiry alerts
Never get caught by an expired certificate again.
An SSL monitor inspects the TLS certificate a host actually presents, works out how many days are left on it, and alerts you before that number reaches zero. Expired certificates don't degrade gracefully: browsers replace the page with a full-screen warning, API clients abort at the handshake, and there is no partial service in between. The point of monitoring the expiry date is that the failure is entirely predictable. The date is printed in the certificate months in advance, and the only thing standing between you and an outage is whether anyone reads it in time.
How it works
UptimeAlien checks the certificate's expiry date on a schedule and alerts a configurable number of days before it lapses.
When to use it
- Production TLS certificates
- Certificates outside your renewal automation
- Mail, LDAP and broker certificates on non-standard ports
- Certificates terminated on load balancers and CDN edges
- Compliance and renewal reminders
What you get
Days until expiry, the exact expiry date, how long ago it lapsed if it already has, and an alert at the lead time you set.
Example
*.acme.com, warn 14 days before expiry
Automated renewal is not the same as a guarantee
ACME clients turned certificate renewal into a background process, and background processes fail quietly. A renewal hook that was never re-created after a server migration. A DNS-01 challenge that stopped validating when the nameservers moved. A cron job disabled during a maintenance window and never switched back on. A certificate sitting on a load balancer, a CDN edge or a mail server that was never part of the automation in the first place. None of these produce an error anyone sees. The logs are on a machine nobody reads, and everything keeps working right up to the expiry date. Then browsers show a full-page interstitial, API clients abort on a TLS error, and mobile apps that pin certificates stop talking to you entirely. A certificate monitor checks from the outside and depends on none of your automation, which is exactly why it still reports when the automation is the thing that broke.
The monitor reads the expiry date and passes no judgement on the trust chain
The check opens a TLS connection to the host, sends the hostname via SNI so it receives the right certificate on a shared IP, reads the expiry date from the certificate the server actually presents, and turns that into days remaining. It does not judge the trust chain: a self-signed certificate, one from an internal CA, or a staging host with a mismatched name is monitored exactly like a publicly trusted one. That is deliberate, because the question this monitor answers is “when does it expire”, and internal services deserve an answer too. If you also want “does a browser trust this”, put an HTTP monitor on the same URL: that check fails at the TLS handshake when the chain is broken, an intermediate is missing, or the name doesn't match. The two together cover both halves, and they cover them independently of each other.
Certificates live on more than port 443
The certificates that actually catch people out are rarely the ones on the website, since that one is watched by everybody. It is the SMTP submission certificate on port 465, IMAP on 993, LDAPS on 636, the MQTT broker on 8883, the Postgres or RabbitMQ instance behind a TLS listener. When one of those expires there is no warning page and no visible outage. Mail delivery simply stops, a queue consumer disconnects and reconnects in a loop, an integration starts failing at a rate somebody will get around to investigating next week. Enter the target as host:port and the check goes wherever the certificate is. A full URL works too: the scheme, path and query are stripped and the port is taken from it, so pasting an address straight out of your browser does the right thing.
Lead time: 14 days on ACME, 30 on manual renewal
The warning window is set per monitor, anywhere from 1 to 90 days, and defaults to 7. Seven days is enough to notice but not always enough to act: an alert that lands on a Friday evening leaves two working days. The right value depends on how the certificate is renewed. For an ACME certificate with a 90-day lifetime, 14 to 21 days is the useful range. Automation normally renews at 30 days remaining, so an alert at 14 is unambiguous: the renewal did not happen, and it is not going to happen on its own. For a manually renewed one-year certificate, 30 days is more realistic, because purchasing, validation and an approval step take longer than the actual work does. Going much wider is counterproductive; an alert that fires two months ahead gets acknowledged and forgotten, and the monitor then sits red for weeks until it stops meaning anything at all.
Frequently asked questions
What is SSL certificate monitoring?
It checks the expiry date of your TLS certificate on a schedule and alerts you a configurable number of days before it lapses, so a renewal never gets missed.
How do I set up SSL certificate monitoring?
Create a monitor of type SSL, enter the hostname, adding :port if the certificate isn't on 443, and set how many days before expiry you want to be warned. The first check runs on the next scheduling pass and reports the expiry date it found; from then on the monitor stays green until the remaining days drop to your threshold.
Why monitor certificates if renewal is automated?
Automation fails quietly: a renewal hook breaks, a DNS challenge stops validating, a cron job is disabled during a migration. You usually find out when browsers start showing a full-page warning. A certificate monitor turns that into an early notice.
How many days of warning should I configure?
Enough to renew comfortably. Two weeks is a common choice, long enough to react without ignoring the alert, short enough that it stays meaningful. For manually renewed certificates 30 days is a better fit, since procurement and approvals take longer than the work.
Can I monitor certificates on ports other than 443?
Yes. Write the target as host:port, so mail.acme.com:465 for SMTP submission, imap.acme.com:993, broker.acme.com:8883 for MQTT. Without a port, 443 is assumed.
Where do the expiry alerts go?
Wherever you route them: email, Slack, Discord, Telegram, PagerDuty, Opsgenie, ntfy, Gotify, a webhook, an MQTT topic, or a push notification on the Android app. Channels are configured per monitor, so certificate warnings can go somewhere other than outage alerts, which is useful, because one is a task for this week and the other is an emergency.
What happens once a certificate has already expired?
The monitor goes down and the alert states how long ago it lapsed, instead of just repeating that it is due. That distinction matters when you come back to a stack of notifications and need to tell what is already broken from what is about to break.
Does it check the whole certificate chain?
No, it reads the expiry date of the certificate the host presents. Intermediates have their own, much longer lifetimes and are replaced by the CA. If you need the full chain validated, an HTTP monitor on the same host does that as a side effect: a broken chain fails the TLS handshake and the check goes red.
Does it work with wildcard certificates?
Yes, wildcard certificates are checked in the same way as certificates issued for a single hostname.
Is there an API for SSL certificate monitoring?
Yes. POST /api/v1/monitors creates a monitor with an API token, taking the kind, the target and certWarnDays in the body; a GET on the same path lists them together with the last expiry date each check found. Certificates can therefore be registered by the same automation that issues them.
Does this monitor also watch the domain's expiry?
No, that has its own type. Certificate and domain carry separate expiry dates and very different consequences: a certificate expires every few months and usually renews itself, while a domain registration expires after years and can then only be recovered with effort and cost. Use domain expiry monitoring for that.
Set up your first monitor. Free.
Get started for freeOther monitoring types
Related feature: Expiry monitoring