Every HTTPS-serving website in 2026 depends on a short piece of cryptographic paperwork — the SSL/TLS certificate — that has an expiry date baked in. Let the date pass without renewing the certificate, and browsers will refuse to connect. Your site is technically running, your server is technically up, and yet to any customer attempting to visit, it is as unavailable as if the machine had been unplugged. The embarrassing part is that expired-certificate outages are entirely preventable, which is precisely why they sting so much when they happen. This guide walks through how to use Uptime Kuma's SSL certificate monitoring to stop them happening to your UK business. For the wider context on why this sort of monitoring exists, see our introduction to Uptime Kuma.
Why expired certs still cause outages in 2026
Let's Encrypt has made free, automated TLS certificates the default for virtually every website published in the last eight years. You might reasonably assume that, with automation in place, expired-certificate outages would be a thing of the past. They are not. UK businesses still lose hours to them every year, for four predictable reasons.
Auto-renewal fails silently. Let's Encrypt's ACME protocol renews certificates before they expire, but the renewal depends on the renewal agent being able to prove domain control. If the HTTP-01 challenge path is blocked by a firewall change, if the DNS challenge configuration drifts, if the machine running certbot was rebuilt without reinstalling the cron job — the renewal quietly stops happening. Nobody notices until the certificate actually expires.
Someone renewed the wrong certificate. Larger estates have multiple certificates across multiple hosts. A maintenance engineer tidies up a machine and accidentally removes the certificate for a rarely-visited subdomain, unaware that a third-party integration depends on that subdomain being reachable.
The CA changed its root chain. This is rare but it has happened — most memorably when Let's Encrypt's original cross-signed intermediate expired in 2021 and millions of older devices stopped trusting certificates from servers that had not updated their chain. Your server is serving the right certificate; the client cannot verify it.
Manual renewal on a long cycle. Some certificates — particularly organisation-validated (OV) or extended-validation (EV) certificates used by UK financial services, local government and larger enterprises — cannot be automated. Someone has to renew them manually, on a schedule measured in years. That someone leaves, changes roles, or simply forgets. The certificate expires because the calendar reminder never reached anyone who could act on it.
All four failure modes are detectable if and only if something watches the certificate. That something is usually a monitoring tool. Relying on browser warnings, customer complaints, or the memory of a single administrator is the pattern that produces the annual UK business news story about a famous site that went offline for half a day because a certificate expired on a bank holiday weekend.
How Uptime Kuma's certificate check works
Uptime Kuma does not have a separate "SSL monitor" type. Certificate checking is built into the HTTP(s) monitor as a silent, free bonus. Every time Uptime Kuma makes an HTTPS request to a monitored URL, it reads the certificate served by the server, records its subject, issuer, valid-from and valid-to dates, and checks the chain up to a trusted root.
This means that, if you already have an HTTP(s) monitor configured against every URL that matters — and you almost certainly should; our HTTP(s) monitoring guide is the foundational read — you already have SSL certificate monitoring. What you need to do to make it useful is configure the expiry notifications. By default, Uptime Kuma fires warnings at 14 and 7 days before certificate expiry. You can tune those thresholds per monitor, which is the right place to be if you have a mixture of certificate lifetimes.
The check has one limitation worth being aware of: Uptime Kuma reads the certificate that the server actually serves on each request. If you are behind a CDN that terminates TLS at its edge — Cloudflare, Fastly, Akamai — what Uptime Kuma sees is the CDN's certificate, not the one your origin serves. For most customer-facing monitoring that is exactly what you want, because what matters is what the customer actually sees. If you specifically need to verify origin certificates independently, you will need a monitor that speaks to the origin directly, bypassing the CDN.
Tuning the expiry warning thresholds
The default warning points — 14 and 7 days — suit most deployments. They are worth adjusting in three scenarios.
Longer lead time for manual-renewal certificates. If you are responsible for OV or EV certificates that must be renewed manually via a commercial certificate authority, bump the warning thresholds to 30 and 14 days. Manual renewals often require procurement involvement, identity re-validation, and certificate replacement on multiple hosts — you want weeks of warning, not days.
Shorter lead time for short-lived certificates. Some CAs are experimenting with 7-day or 14-day certificates. If your certificate lifetime is measured in days, a 14-day expiry warning is meaningless because the certificate barely lives that long. Tighten to something sensible — perhaps 2 and 1 days — and trust that the automation is rotating certificates continuously.
Team absence protection. UK teams disappear for several days at a time around major holidays. August bank holiday, late December into early January, the May bank holidays — these are predictable absence windows. Bumping the warning threshold to cover the longest likely absence period means that a renewal issue flagged on 23 December does not sit in an empty inbox until 4 January.
The pragmatic rule of thumb: warn earlier than you think you need to. A warning that fires a week too early is a mild nuisance. A warning that fires a day too late is an outage. Most UK teams who have experienced an expired-certificate incident once tend to err heavily on the side of earlier warnings for years afterwards.
Chain issues vs simple expiry
Most certificate failures are simple expiry. A smaller but significant class of failures are chain issues — the certificate is valid, but the chain of trust connecting it to a root authority is broken, mis-ordered, or depends on a root the client does not have.
Uptime Kuma's certificate check catches chain issues because it attempts full chain verification on every request. What you will see when a chain issue is present is an HTTP(s) monitor that flips to down with a TLS verification error in the failure detail, even though a browser user might report that the site "sort of works sometimes". The intermittency is the key tell: older operating systems and older mobile browsers ship with smaller root stores and will fail verification where newer browsers get away with it.
The practical implication for monitoring is to treat TLS verification errors as equally serious as outright expiry. Both mean customers cannot reliably reach your site. In the UI, the failure reason for a chain issue looks different from an expired certificate — it is worth reading the detail rather than assuming every TLS failure is a renewal problem.
Let's Encrypt auto-renewal — what actually goes wrong
Since most UK sites use Let's Encrypt, the specific failure modes of its ACME automation are worth understanding. Uptime Kuma will tell you when a renewal failure has actually resulted in an expired certificate, but understanding the plumbing helps you diagnose why.
HTTP-01 challenge path blocked. Let's Encrypt's default challenge mode requires the renewal agent to serve a specific file at /.well-known/acme-challenge/ on port 80. Reverse-proxy reconfiguration that accidentally blocks this path — a new WAF rule, an over-aggressive redirect to HTTPS — breaks renewal silently. The test is simple: try to fetch a dummy path under /.well-known/acme-challenge/ manually. If it does not return a 200 or a 404 cleanly, the renewal agent cannot complete the challenge.
DNS-01 challenge misconfiguration. DNS-based challenges are the only option for wildcard certificates and for environments where port 80 is not available. They require the renewal agent to write a specific TXT record during renewal. If the API credentials for the DNS provider have rotated, or the DNS provider changed its API, renewal stops working without any change on your server.
Rate limit hit. Let's Encrypt applies rate limits per domain. Teams running CI that obtains fresh certificates on every pipeline run can accidentally hit the rate limit, at which point renewals are rejected for a few days.
Stale certbot, stale Node.js. A legacy certbot installation using deprecated ACME v1 endpoints will eventually stop working. Keeping the renewal agent up to date is part of the operational cost of self-hosting.
Permission changes on the certificate store. The renewal agent needs write access to the directory where certificates live. System updates, filesystem migrations or security hardening exercises occasionally change these permissions without anyone noticing. The agent then fails silently at write time. Uptime Kuma's certificate check catches this because the server continues to serve the old, expiring certificate while the new one cannot be installed.
Server reload not triggered after renewal. On many setups, the renewal agent writes a fresh certificate to disk but relies on a post-renewal hook — a command that reloads the reverse proxy — to actually pick it up. If the hook fails or is misconfigured, the server happily keeps serving the old certificate right up to the expiry minute. Monitoring is the only thing that catches this one.
A managed Uptime Kuma plan on smartxhosting.uk gives you a fresh Uptime Kuma instance on UK infrastructure. You log in, create the admin account and configure HTTP(s) monitors for the sites you care about — the certificate checks come along automatically on those monitors. The SSL certificate of the Uptime Kuma instance itself is handled by the provider, so your monitoring is not taken offline by a renewal problem on the monitoring platform.
Wildcards and SAN certificates
Many UK SaaS businesses use wildcard certificates (*.your-brand.co.uk) to cover any subdomain they ever create without issuing per-subdomain certificates. A single Uptime Kuma HTTP(s) monitor against any URL on that wildcard will check the expiry of the whole wildcard certificate, because the wildcard is served on every subdomain that uses it.
SAN certificates — certificates that cover multiple specific subject alternative names — work similarly. Whatever URL you monitor will verify the same certificate, so checking the certificate's expiry is a solved problem regardless of how many names are on the SAN. What wildcards and SANs do not save you from is different certificates across different subdomains. If app.your-brand.co.uk is on a wildcard but status.your-brand.co.uk uses a separate, individually-issued certificate, the monitor on the wildcard subdomain will not catch an expiry on the other one. A single monitor per certificate is the rule.
UK-specific considerations
A few certificate-monitoring concerns affect UK businesses more than others.
Public sector and government CAs. Local councils, NHS trusts and central government services frequently use certificates from specific authorised UK CAs rather than general-purpose free issuers. Renewal lead times are longer, renewal costs money, and automation support is patchy. Expiry warning thresholds should be generous — 30-60 days is not excessive for these certificates.
Financial services and OV/EV certificates. UK banks, insurers and fintechs are routinely required by risk policy to use OV or EV certificates on their customer-facing sites. These are fully manual to renew and expensive. Every such certificate should be on a monitored endpoint with the longest practical warning threshold.
.gov.uk and .nhs.uk domains. These domains have additional governance around certificate issuance. If you operate an integration that terminates on such a domain, confirm your monitoring covers it — mistakes here have compliance implications beyond the simple availability question.
Old mobile devices. The UK has a wider distribution of older Android devices in the field than some European markets. If chain verification breaks for a cross-signed intermediate, customers on older devices may see errors before customers on newer ones. Test your chain against an older root store periodically; Uptime Kuma's verification uses a modern root store by default, so it will not catch this case on its own.
Patterns for estates with many certificates
Once you have more than a dozen certificates across multiple subdomains and third-party properties, a few patterns emerge.
One monitor per certificate, not per URL. If five URLs share a wildcard, one monitor is enough. If two URLs sit behind different certificates, you need two monitors. Track which URLs are covered by which certificate in a spreadsheet or README so you know at a glance which monitors are certificate-bearing.
Tag certificate-critical monitors. Uptime Kuma's tag feature is perfect for this. A cert-critical tag on every monitor that represents a certificate-bearing URL gives you a dashboard view of "all my certificates" without any additional tooling.
Separate notification channel for certificate alerts. Certificate expiry warnings fire weeks before the outage; they are low-urgency. Routing them into a less-urgent notification channel — a dedicated email list rather than a Slack channel everyone silences — keeps them visible without generating alert fatigue. Our SMTP notifications guide covers how to set up an email-only channel for these.
Audit quarterly. Even with monitoring in place, a human should review the list of certificates every quarter. Monitoring catches what it is configured to catch; a new subdomain added without adding a monitor will still surprise you when its certificate expires. The audit does not need to be heavyweight — ten minutes with a spreadsheet of certificates against a spreadsheet of Uptime Kuma monitors catches gaps quickly.
Document the renewal path. For every manually-renewed certificate, document who is responsible, what the renewal steps are, where the private key lives, and who is a backup if the primary owner is unavailable. Certificate renewals often go wrong when the person who knew how to do it last time is not the person trying to do it this time.
Test renewal during a non-urgent period. The worst time to discover your renewal procedure is broken is two hours before expiry. Scheduling a practice renewal a month before the certificate is due — even if the result is simply "the existing certificate is now replaced with one from slightly-further-in-the-future" — surfaces any problems while you still have weeks to fix them.
For anyone choosing between Uptime Kuma and commercial alternatives for certificate monitoring specifically, our Uptime Kuma vs Uptime Robot comparison covers the feature-by-feature differences.
Summary
Certificate monitoring is free in Uptime Kuma — every HTTP(s) monitor already does it. What you have to do is configure sensible expiry warning thresholds, pay attention to TLS verification failures as distinct from outright expiry, understand the specific ways Let's Encrypt auto-renewal can fail, and keep an eye on the commercial certificates that cannot be automated. Estates with more than a dozen certificates benefit from tagging and a dedicated quieter notification channel for low-urgency expiry warnings. None of this is complicated; all of it is measurably valuable because the alternative — finding out from a customer ticket that your site is serving an expired certificate — is exactly the sort of avoidable, embarrassing outage that monitoring tools exist to prevent.