Monitor apex and www SSL separately

Monitor www and root ssl as distinct scheduled checks because apex and www are different handshake names—even when marketing treats them as one brand URL.

Operators assume a redirect unifies risk: users “always” land on www, so only www needs a watch. Browsers still open TLS to whichever name was typed or linked. SEO crawlers and email clients hit apex directly. Certificate material can differ when one name terminates on a CDN default and the other on origin ACME.

Procurement counts “one website” while reliability engineers need two rows in monitoring inventory. That mismatch drives incidents where www is green and example.com is not.

This guide explains when apex and www share a cert, when they diverge, and how separate live TLS watches fit plan caps from free three-domain pilots to Starter 25 hourly portfolios.

What you are actually buying

Monitoring products sell per-hostname external handshakes. Monitor www and root ssl means two probes, two alert streams, and two entries in your portfolio cap—even if one HTTP redirect makes humans rarely notice apex breakage.

Shared SAN certificates can cover both names with one renewal event. Renewal unity does not guarantee presentation unity: partial deploys, stale CDN attachments, or wrong vhost bindings leave one name expired while the other serves fresh material.

Live TLS checks reveal that split. Disk inventory on the origin may show one PEM while the apex edge still serves an older leaf.

Redirects also do not skip PKIX validation—the first connection completes TLS on the typed host. See fix expired SSL certificate patterns when only one alias fails in the field.

Pair apex and www strategy with how many domains to monitor so brand counting stays honest.

Evaluation checklist

When you monitor www and root ssl, verify vendors and runbooks against these ten points.

1. Separate enrollment rows. Apex and www must not silently collapse into one slot without documented reason.
2. SNI correctness on each probe. Each name triggers its own servername extension.
3. Redirect awareness without false fusion. Tools may note 301 chains but still alert per hostname.
4. SAN visibility. Shared cert should show matching serial on both probes when presentation is healthy.
5. CDN vs origin divergence detection. Edge and origin may disagree; external checks reflect customer path.
6. Threshold alerts per name. 30/14/7/1 day emails should identify which alias is at risk.
7. Portfolio cap planning. Two names per brand doubles consumption of three free or 25 Starter slots.
8. Hourly cadence on revenue aliases. Daily may suffice on marketing-only hosts; checkout apex/www pairs often need hourly—see daily vs hourly.
9. RDAP on brand domain. Registration expiry is usually one row per registrable domain, distinct from TLS alias rows.
10. One-shot checks on both names. Validate each via public check before enrollment.

Run openssl or browser tests on both names after every CDN migration, not only the canonical URL in the style guide.

How ssldays fits

ssldays treats apex and www as separate monitored hostnames when you enroll both. Each receives live TLS measurement on its plan cadence—daily on free (3 domains) and hourly on Starter (25 domains) and Pro (100 domains).

Email alerts at 30, 14, 7, and 1 days identify the failing hostname. Slack and Discord webhooks on paid tiers help route apex regressions separately from www noise if you configure channels that way.

A three-domain free pilot commonly burns two slots on apex and www for the primary brand, leaving one for API or admin—plan upgrades before you add a second brand with the same pattern. Starter hourly coverage supports agencies juggling multiple client apex/www pairs; see monitor client SSL certificates for portfolio grouping.

Compare enrollment with Certbot multiple domains one cert renewals: one ACME event, two external witnesses.

Use check on both names after deploy night.

Common mistakes when choosing a monitor

Watching only the canonical host in analytics. Traffic-weighted choice hides apex bookmarks and legacy links.

Assuming HSTS preload removed apex risk. Preload lists still reference both names in many migrations.

One monitoring row because “cert covers both.” Coverage on paper does not prove both paths serve it.

Ignoring IPv6-only or split-horizon DNS differences. Apex and www may resolve to different edges.

Collapsing www and apex in client contracts. SLAs should list both when both are public.

Skipping hourly on apex when www is hourly. Mismatched cadence preserves blind spots.

Next steps

List every brand’s apex and www in your DNS export. Mark whether each terminates on CDN, load balancer, or origin.

Enroll both on ssldays or run live checks weekly until enrolled. After ACME renewals, re-verify both names externally—reload gaps often hit only one vhost.

If two names per brand pushes you past three free domains, budget Starter for 25 hourly watches. Read starter plan 25 domains hourly for upgrade timing.