What SSL certificate monitoring catches
Uptime Tracker treats a bad TLS certificate as an outage, because to a visitor it is one: browsers show a full-page warning and most people leave. On every HTTPS check the certificate is validated, and the check fails if any of these is true:
- The certificate has expired. The most common cause is an automated renewal that silently stopped working.
- The certificate is untrusted. For example a self-signed certificate, a missing intermediate certificate, or a chain that does not lead to a trusted root.
- The hostname does not match. The certificate was issued for
www.example.combut the monitor requestsexample.com, or a load balancer is serving the wrong certificate for a domain.
When the check fails, the normal failure confirmation applies: the monitor is re-checked, and two consecutive failures open an incident and send alerts to your channels. Because the certificate is checked at the monitor's interval, a broken certificate is caught within minutes on Free and within about a minute on Starter or Team.
Missing intermediates and hostname mismatches are worth calling out. They often appear right after a server migration, CDN change or new load balancer, and they may not show up in your own browser if it has cached the intermediate certificate. An independent check catches them for everyone.
Certificate expiry dates and renewal planning
The certificate expiry date is shown on every HTTPS monitor, so you can see at a glance which certificates are close to renewal. If a certificate does expire, the next check fails and you are alerted immediately.
Uptime Tracker does not yet send separate advance-warning emails before a certificate expires. Here is what that means in practice and how to cover it:
- Automated renewal (for example Let's Encrypt with certbot or a managed CDN): certificates renew about a month before expiry. If renewal breaks, you see the expiry date approaching on the monitor, and an expired certificate triggers an alert. Pair this with a heartbeat on the renewal job to catch failures sooner (see below).
- Manually purchased certificates: note the expiry date shown on the monitor in your calendar or ticket system, and review the monitor list as part of a monthly routine.
A useful trick for automated renewals is to monitor the renewal job itself. Add a heartbeat monitor to an hourly task that runs your renewal check and pings only on success. If the renewal tooling breaks, you hear about it from the heartbeat weeks before the certificate would expire.
Exporting your monitors as CSV also gives you a quick inventory of every domain you watch, which helps when auditing certificates across many sites.
Pair certificate checks with domain-expiry monitoring
A valid certificate does not help if the domain registration itself lapses, so the most complete protection pairs SSL checks with domain-expiry monitoring. An expired domain takes down your website, email and every certificate issued for it at the same time, and recovering it can be slow or impossible once it enters the registry's deletion cycle.
The two checks cover different renewal processes:
| SSL certificate check | Domain-expiry check | |
|---|---|---|
| What it watches | The TLS certificate served by your site | The domain registration at the registry |
| Data source | The live HTTPS connection | RDAP registration data |
| Advance warning | Expiry date shown; alert when invalid or expired | Configurable warning 1 to 90 days ahead (default 30) |
| Plan | All plans, including Free | Starter and Team |
Domain-expiry monitors do send advance warnings, so on Starter and Team you get a heads-up weeks before a registration lapses. Together with certificate validation on every HTTPS check, that covers the two renewals most likely to take a working site offline overnight.
Set up SSL certificate monitoring
There is no separate SSL monitor to configure: any HTTPS monitor validates the certificate automatically.
- Sign in and add an HTTP(S) monitor using the
https://address of your site. - Add a monitor for each hostname that has its own certificate, for example
example.com,www.example.com,app.example.comandapi.example.com. Each one may be served by a different certificate or server. - Choose alert channels. Certificate failures arrive through the same channels as downtime alerts.
- Open the monitor to confirm the certificate expiry date is shown.
- On Starter or Team, add a domain-expiry monitor for each registered domain.
Monitoring each hostname separately matters. A common failure is a certificate that covers www but not the bare domain, or a subdomain served from a different platform whose certificate is renewed on a different schedule. One monitor per public hostname catches those cases.
If you manage many client sites, import them in bulk with CSV. See uptime monitoring for agencies for a setup that groups sites by client.
What's included on each plan
SSL certificate validation is part of every HTTPS check on every plan; what changes between plans is how quickly a broken certificate is detected and how alerts are routed.
| Free | Starter | Team | |
|---|---|---|---|
| Certificate validation on HTTPS checks | Yes | Yes | Yes |
| Expiry date shown on monitor | Yes | Yes | Yes |
| Check interval | 5 minutes | 60 seconds | 30 seconds |
| Domain-expiry monitors with advance warnings | No | Yes | Yes |
| SMS and routing rules | No | Yes | Yes |
The check interval is the main reason to upgrade for certificate monitoring. On Free, a certificate that breaks during a deploy is caught within about 5 minutes plus a confirmation re-check; on Starter and Team it is caught within a minute or two. For a busy store or SaaS login page, that difference is real.
Starter also adds domain-expiry monitors with advance warnings, which complement certificate checks, and SMS alerts with routing rules so certificate failures on critical hostnames reach a phone. See the pricing page for all limits.
