SSL monitoring

An expired SSL certificate is the most preventable outage in production. Browsers show a full-page security warning, API clients hard-fail the TLS handshake, mobile apps error out — and to every user it looks like your service is broken or compromised. It happens to teams of every size, and it almost always happens for the same reason: everyone assumed renewal was automated, and nobody was watching whether the automation actually worked.

SSL monitoring is the safety net under that automation. FourSight connects to your endpoint, inspects the certificate actually being served, and counts down the days — alerting on a schedule that gives you time to fix a broken renewal calmly rather than during an outage.

Because automation fails silently. An ACME client gets stuck on a rate limit; a DNS-01 challenge breaks after a nameserver migration; a firewall change blocks the HTTP-01 validation path; the renewal cron job itself dies (see cron job monitoring); or the cert renews on the origin but a load balancer, CDN edge, or legacy appliance keeps serving the old one. In every one of those cases the renewal system believes it succeeded — or doesn't run at all — and no error ever reaches a human.

Monitoring from the outside sidesteps the entire question of why. FourSight doesn't inspect your renewal tooling; it inspects the certificate your users actually receive during a real TLS handshake. If that certificate is 29 days from expiry, you get an alert — regardless of what certbot's logs claim.

Reminder emails are addressed to whoever created the certificate, which after a couple of years is frequently a departed employee, a defunct distribution list, or an agency that no longer holds the contract. They land in inboxes nobody checks, get swept into spam, or arrive at the parked address behind a WHOIS privacy service.

The bigger structural problem: the industry is moving away from reminder emails entirely. Let's Encrypt — which issues the majority of certificates on the web — ended its expiration notification emails in 2025, explicitly telling users to rely on monitoring instead. Meanwhile certificate lifetimes keep shrinking (the CA/Browser Forum has adopted a schedule that pushes maximum validity down dramatically over the next few years), which means more renewals, more often, with more chances for the automation to break. An email that might reach the right person is not a control; an alert wired into your on-call escalation policy is.

Each check performs a real TLS handshake against your endpoint from FourSight's probe network and records the certificate evidence — issuer, subject, SANs, and the exact expiry timestamp — so every alert comes with the data to act on.

SSL check coverage

Check	What it catches	Default
Expiry countdown	Certificate approaching its notAfter date	Alerts at 30, 14, and 7 days (configurable)
Host mismatch	Valid certificate served for the wrong hostname (SAN doesn't cover the domain)	Enabled
Chain validity	Missing or broken intermediate certificates that fail strict clients	Checked on every cycle
Handshake failure	Endpoint no longer completing TLS at all	Incident opened via quorum

Tip: The default 30/14/7 ladder is deliberate: 30 days catches a broken auto-renewal while there's still time to debug it calmly, 14 days escalates, and 7 days is the final page before it becomes an emergency. You can set any thresholds that fit your renewal window.

A certificate can be perfectly valid — trusted chain, months of life left — and still break your site, because it's the wrong certificate. This happens constantly in practice: a CDN or load balancer falls back to its default certificate after a configuration change, a wildcard cert gets deployed to a domain it doesn't cover, or a migration points traffic at a server still serving another tenant's cert. Browsers treat all of these as hard security failures.

Expiry-only checkers miss this class of outage completely. FourSight verifies on every check that the certificate's subject alternative names actually cover the hostname being monitored, so a mismatch pages you the same way an expiry would — usually within one check cycle of the misconfiguration going live.

Single-purpose SSL trackers exist, and some are free. The problem is fragmentation: SSL expiry is one of at least eight things that can silently take a production service down, next to DNS drift, domain expiry, dead cron jobs, and plain HTTP outages. Each standalone tool is another dashboard, another alert channel to configure, another account that lapses when its owner leaves.

FourSight's Growth plan bundles SSL monitoring with all eight check types — HTTP, keyword, DNS, domain expiry, ping, port, and heartbeat — under one escalation policy and one status page, at $40/mo flat for 100 monitors. Monitor every certificate you own, including internal and staging endpoints, without counting seats or paying per check.

Included in Growth — $40/mo flat

Never get surprised by an expired certificate again

SSL monitoring is included in the Growth plan with all eight check types, 30-second intervals, 4-region validation, and escalation policies — flat pricing, no per-certificate fees.

• Alerts at 30, 14, and 7 days before expiry — thresholds configurable per monitor
• Host-mismatch and chain validation on every check
• Certificate evidence (issuer, SANs, expiry) attached to every alert
• Email, Slack, webhook alerts — SMS on Pro and above

FAQ