When Your Customers' Certificates Become Your Problem
Your SaaS platform's uptime is held hostage by your customers' DNS and certificate hygiene. They point a CNAME at your service, you serve traffic for their domain, and when their certificate breaks - or their DNS misconfigures, or their wildcard doesn't cover the subdomain they pointed at you - the failure looks like a problem with your platform.
Customers experience it as "the SaaS is broken." Their customers, who don't know which company runs which part of the stack, experience it as "the website is broken." You get the support ticket.
The trust-shift problem in custom domains
Most SaaS platforms offer custom-domain support: the customer maps app.theircompany.com to your platform. There are a few ways this can be set up:
- The customer holds the certificate. They issue and renew the cert for
app.theircompany.comand provide it to you, or you proxy traffic and they terminate TLS at their edge. - You hold the certificate. They delegate via CAA records and HTTP-01/DNS-01 validation; you issue and renew on their behalf. Common with ACME-based platforms.
- A hybrid. They issue the cert, you store and serve it, renewal is on their schedule.
In every model, something on the customer's side can break. Their DNS expires. Their CAA records change. Their wildcard cert lapses. Their domain registrar loses the credentials. Their compliance team decides to rotate everything on a different schedule. The cause varies; the symptom is consistent: a chunk of your platform appears down to that customer's users.
What you can monitor that they can't
You have visibility your customer doesn't. They see their own domain and their own cert. You see the full population of your customers' custom domains, the pattern of failures across them, and the lead time on most issues - the cert that expires next month is something you can flag before it breaks, whether or not the customer is watching their own clock.
Specifically, three categories of monitoring you can do that customers usually can't:
- Expiry tracking across all customer domains. A central inventory of every
customer-X.yourplatform.complus everyapp.customerX.com, with alerts before each renewal window. Customers don't have to remember; you remember on their behalf. - DNS health checks. CNAME chains that resolve correctly today might not tomorrow if the customer changes their DNS provider, updates a record incorrectly, or lets a domain expire. Continuous probing catches these before they impact traffic.
- Certificate chain validation. The customer's cert might be valid by date but missing intermediates, mismatched on hostname, or issued by a CA that's been distrusted (DigiCert G1 in April, Entrust in 2024). Catching these requires more than reading the cert's expiry field.
Operationalizing customer-domain monitoring
The teams that do this well make it part of customer onboarding. The custom-domain setup flow includes adding the domain to monitoring; the customer doesn't have to opt in or remember to register it separately.
The alerts route to two places: your customer-success or support team (so they can proactively reach out to the customer when an issue is detected), and optionally the customer themselves via email or webhook (so they can fix what's on their side). The dual routing matters because customers don't always act on alerts to "their" team; sometimes the platform reaching out is what triggers action.
At meaningful customer volume, the operational question becomes: what fraction of customer custom-domain incidents do you catch before they become support tickets? Without monitoring, the answer is roughly zero. With it, most.
The SLA implication
Your uptime SLA is usually written against your platform. Your customers' uptime is what their customers measure. If their cert breaks and your platform appears down, the SLA discussion gets uncomfortable - whose fault is it, technically, doesn't help when retention is on the line.
Proactive monitoring of customer domains effectively extends your operational responsibility past the strict boundary of your service. It's more work, but it's the work that keeps customers happy when something on their side breaks.
For platforms with hundreds or thousands of custom-domain customers, this monitoring is a meaningful product capability - and it's not something most teams want to build from scratch given the cert-handling, DNS-monitoring, and alerting complexity involved.
Stop letting customer cert hygiene own your uptime
TLS Radar monitors customer custom domains alongside your own: expiry tracking, DNS health, chain validation, CA distrust detection. Alerts route to customer success, support, or the customer directly. Built for SaaS platforms managing hundreds or thousands of customer-mapped domains, with API integration, SAML/SSO, and pricing that fits your customer volume. Tell us how custom domains work in your platform.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.