SSL certificate monitoring, what it is and what it isn’t.

SSL certificate monitoring is the boring safeguard that closes the gap between a server that answered and a visitor who landed on the browser warning page. Half of the "my site is down" messages I receive are the cert having gone bad on a renewal path that should have been automatic. The renewal is supposed to be silent. When it isn’t, you find out from the visitor, not from your monitoring — and by then the trust you lost is not invoice-recoverable.

The right shape of the watch is dated and exact: a daily probe that reads the cert path the way a browser does, with an alert cadence that fires long before the expiry date lands. The cadence that's worth the trust is the same one the cert-expiry cadence piece walks through, and the same one the monitoring benchmark testifies against on the live web.

What SSL certificate monitoring actually is

SSL certificate monitoring is a probe that reads the cert path your visitors reach on a schedule, reads the expiry, and emails you at fixed lead times before the cert expires. The probe is small. The probe is daily. The probe reads the chain a browser would read, including any intermediate certs the chain depends on.

What it isn’t: it isn’t a renewal service. The probe does not renew your cert; your CA does that, on its own schedule, with its own account. It isn’t a malware scanner. It doesn’t watch for mixed-content warnings or for the page contents the visitor sees after the cert is accepted. It just asks "is the cert path valid and when does it go bad?" That is the entire surface. The cheaper tools you can buy do exactly this and almost nothing else.

For a deeper walk through the daily-probe mechanics, see the SSL expiry monitor pillar. The pillar covers the operational shape of the watch; this article covers what the watch is for and how to read the metrics that come out of it.

The 90 / 30 / 7 / 1-day window that’s worth the trust

The alert cadence that’s worth the trust is dated in four lead times: 90 days, 30 days, 7 days, and 1 day before expiry. Ninety days out is the first chance to learn the renewal path has broken. Most managed hosts renew at thirty days out, so a 90-day alert is the first confirmation that the auto-renew ran cleanly. A 30-day alert is the deadline: if you have not heard from any platform by now, you need to trigger the renewal manually. A 7-day alert is the last warning before some platforms refuse to renew at all. A 1-day alert is the "migrate before the browser warning page renders" email.

What the cadence is not: a single bullet fired at expiry. The single-bullet pattern means a fire drill at 11pm when the cert is already bad and the visitor has already met the warning page. The four-step pattern means four chances to renew or migrate before the warning page appears. The four-step pattern is what every modern managed host is built to handle.

What the live web actually looks like

The data point most worth knowing on a small shop is the share of the live web whose cert expires within fourteen days of measurement. The monitoring benchmarktracks exactly that, published with a "Cite as:" block next to the figure so the citation is fragment-stable. The number is small but not zero, and the small-but-not-zero shape is what motivates the daily probe more than any quarterly summary ever will.

The second data point worth knowing is the share of the live web whose cert is genuinely invalid — expired, name-mismatched, or issued by a CA the browser no longer trusts. The broken-cert bucket figure is in the same order of magnitude — about one percent, give or take — and is the figure the cert authority uses to size the renewal team. The third figure, the top-three cert outage vector, is the one small shops actually have to plan against: the renewal path that fails silently because a setting is wrong on the host.

All three figures are fragment-stable against the benchmark page, which means any article citation lands a reader on the exact figure being referenced. They are the most citatable SSL figures in the category, and they are the ones this piece leans on.

The four comparison families worth weighing

SSL certificate monitoring is rarely the only thing a small shop buys. Most shops in the category already buy one of four comparison tools — the comparison hub at /vs/all lays out the decision matrix — and most of those tools do their own cert check as a side feature. The honest comparison is which tool’s cert check is worth the trust, and which is worth the alert cadence above.

The first family is the free uptime monitors. The SiteGuardian versus UptimeRobot comparison walks through what UptimeRobot’s free tier covers and where it stops being enough. The cert check on the free tier is real but it fires at one lead time, not four.

The second family is the developer-grade error trackers. The SiteGuardian versus Sentry comparison walks through why Sentry is built for the engineering team, not the founder inbox. Sentry does not include a cert check on any tier; it is a different shape of tool.

The third family is the smaller uptime monitors with a broken-link crawler side. The SiteGuardian versus Oh Dear comparison walks through why Oh Dear ships broken-link crawling, cert expiry, and SSL monitoring in one product. For shops that already use Oh Dear for the broken-link side, the cert-expiry alerting is the same shape as the home-page uptime alerting and shares a dashboard.

The fourth family is the modern uptime-plus-incident-management products. The SiteGuardian versus Better Stack comparison walks through where Better Stack’s community tier stops being enough and what the upgrade actually buys. Better Stack ships a status page and multi-region checks; the cert-expiry alerting is a different cadence from the loud-failure alerting on the home page.

What a layered stack looks like in practice

The daily cert probe is one piece of a layered monitoring stack. The home-page uptime probe is another. The broken-link crawl is another. The checkout-failure and form-failure probes are two more. The layered stack is the four-piece base monitor plus five layered monitors that close the gap the four-piece leaves open. The cert probe is the piece every small shop forgets until they have missed a renewal.

The shape founders tend to want is the one that does not require a separate monitor for each failure mode. SiteGuardian ships a daily cert probe on the same tier as the other layered monitors — Starter, Pro, and Lifetime — which is why the cert-expiry alerting lives on thepricing page with no add-on tier.

If you would rather see it on your own shop

Run the free URL audit on your home page. It pings the page, reads the cert chain, crawls a handful of outbound links, and reports what it sees in under thirty seconds. The report tells you, in plain English, what the cert chain actually says today and how soon the next renewal cycle lands.

If the audit shows the cert is healthy, the layered stack with a daily cert probe is the boring safeguard. If the audit shows the cert is wider than it has to be, the SSL expiry monitor pillar walks through how to prune the SAN list before the next renewal cycle. If the audit shows the cert is already expired, the cert-renewal path is the first thing to fix, before any other monitoring piece is worth adding.

What the next step looks like

The cheapest defensible path from here is the layered stack: a daily cert probe on every plan, the home-page uptime probe on the same tier, and a pricing entry that does not require a separate cert-expiry add-on. The cert-expiry-inclusive pricing starts at nineteen dollars a month for one site, with no add-on tier, no surprise upgrade, and the same 90 / 30 / 7 / 1-day cadence on every paid tier.

For shops that already use Oh Dear for the broken-link side, the comparison is laid out in SiteGuardian versus Oh Dear. The two tools coexist on most shops; the comparison page walks through which one fits the daily inbox the shop is willing to read. The deeper comparison hub, covering UptimeRobot, Sentry, Better Stack, and the other twelve comparison leaves, is at /vs/all.