An expired SSL certificate does not fail quietly. Every visitor gets a full-screen browser warning that basically says “this site may be dangerous” — over a renewal somebody simply forgot.
Certificates expire on a schedule known months in advance, yet expired-certificate outages keep happening to careful people — because the reminder lived in someone's inbox, diary or memory. Uptime Kuma already reads the certificate of every HTTPS monitor it runs. This guide turns that passive information into an active early warning: check the certificate panel, set the expiry alert, monitor every hostname separately, and verify the new certificate after each renewal.
👆 Example values. The middle row is the entire point: twelve days of warning is a calm renewal; day zero is a public incident.
Open any HTTPS monitor and look at its certificate information — Kuma displays the issuer, the validity dates and the days remaining for the certificate the server presents. The dashboard also flags certificates that are getting close. This panel is your single source of truth: it shows the certificate as visitors receive it, not as the server admin believes it to be — a distinction that matters after botched renewals, where the new certificate was installed on the wrong service and the old one kept ticking.
Inside the monitor's settings you will find the certificate expiry notification option — set how many days before expiry you want to be warned. A practical ladder: 30 days for a first nudge (renewals involving a boss's approval or a paid certificate need the time), and keep the warning attached to the same Telegram or email channel as your down alerts. A warning that arrives in a channel nobody reads is only slightly better than no warning.
A certificate belongs to a hostname, not to a server. Modern servers present different certificates depending on which name was asked for (this is SNI). So monitoring yourwebsite.com says nothing about the certificate on shop.yourwebsite.com — each public name users actually visit deserves its own HTTPS monitor. Wildcard certificates soften this (one certificate covers many subdomains), but the check is free: add the hostname, and let Kuma prove the wildcard is really the one being served.
Renewal is not finished when the hosting panel says success — it is finished when Kuma's panel shows the new expiry date. Automatic renewal (for example with free Let's Encrypt certificates) fails silently more often than people expect: a moved file, a changed web root, a blocked challenge — and the old certificate keeps counting down with nobody watching. The monitor is the receipt that the renewal truly landed. Build the habit: renew, then watch the days-remaining number jump back up.
Internal portals — the NAS login, the printer fleet pages, an intranet app — use certificates as well, and their expiry produces the same frightening warnings for staff. If the machine running Kuma can reach the service over HTTPS, the same monitor-and-warning setup works inside the LAN. The boundary is reachability: Kuma cannot inspect a certificate on a network it cannot touch, so internally hosted Kuma watches internal certificates, and externally hosted Kuma watches the public ones.
Watch the video for the full Uptime Kuma setup — every HTTPS monitor you add there starts watching a certificate as a free bonus.
▶️ Watch Full VideoIt always displays the certificate's days remaining on the monitor, and you can set the expiry notification in the monitor's settings so the warning is pushed to you at the number of days you choose. Set it once — 30 days is a sane start — and attach it to a notification channel you actually read.
Because auto-renewal is a small machine with several moving parts, and it fails quietly: the challenge stops validating, the web server never reloads, the new certificate lands on the wrong service. Your monitor reads the certificate visitors truly receive, so it catches every one of those failures while there is still time.
Yes — include the port in the monitor's URL, like an address ending in :8443, as long as the service speaks HTTPS there and Kuma can reach it. The certificate check follows the same connection as the uptime check.