SSL Monitoring for SaaS Agencies: What to Monitor When Your Clients Run Software Products
Agencies that build and maintain SaaS products for clients face a structurally different SSL monitoring problem than agencies managing marketing websites. A marketing site has one primary domain, maybe a www and non-www variant, and a CDN certificate that renews automatically. The SSL surface is small and the failure modes are predictable.
A SaaS product has more moving parts: an API subdomain with its own certificate, a webhook endpoint that third-party services post to, an OAuth callback URL registered with Google or GitHub, and possibly a multi-tenant custom domain system where each of the client's customers brings their own domain. Each of these carries an independent SSL certificate. Each one expires on its own schedule. Each one can break without affecting the others — and without triggering any alert if you're only monitoring the marketing URL.
This post covers what SaaS agencies should be monitoring for SSL, why each layer matters, and what breaks when you don't.
The SSL Surface of a SaaS Product
The API Subdomain
Most SaaS products expose an API at a subdomain — api.clientproduct.com, or sometimes app.clientproduct.com for a combined API and frontend. This subdomain has its own SSL certificate, issued against its own hostname, separate from any certificate on the marketing domain.
The API subdomain is the highest-consequence SSL failure point in a SaaS product. When the API certificate expires, every API call from every user fails simultaneously. Mobile apps stop working. Third-party integrations break. If the SaaS product has a free tier and paying customers, paying customers are affected equally.
API certificate expiry is particularly damaging because it is usually invisible to standard uptime monitoring. If your monitoring tool checks the marketing domain, it will report the site as up while the API is returning SSL handshake errors to every client. The first signal is often a spike in user support tickets — not an automated alert.
Webhook Endpoints
SaaS products that integrate with Stripe, GitHub, Slack, Twilio, or similar services receive webhook events at an HTTPS endpoint. The SSL certificate on the webhook endpoint must be valid for the third-party service to successfully post to it. Most webhook providers silently drop deliveries to endpoints with invalid SSL — they don't retry indefinitely, and they don't always surface the failure clearly in their dashboard.
When a webhook endpoint SSL certificate expires, Stripe stops confirming payments, GitHub stops triggering CI/CD builds, and Slack stops sending event notifications. The SaaS product continues running, users can log in, but the integrations that make the product useful stop working. The failure is silent and partial — exactly the kind of failure that takes longest to diagnose.
Webhook endpoint URLs are often at a path on the API subdomain — api.clientproduct.com/webhooks/stripe — so if you're monitoring the API subdomain SSL, the webhook endpoint is covered. But some architectures route webhook endpoints through a separate subdomain or a different cloud function URL. Those need to be monitored explicitly.
OAuth Callback URLs
SaaS products that support OAuth sign-in — "Sign in with Google", "Connect your GitHub account" — register callback URLs with the OAuth provider. The callback URL must be HTTPS, and the SSL certificate on that URL must be valid when the OAuth provider redirects the user back after authentication.
An expired SSL certificate on an OAuth callback URL breaks the entire sign-in flow for that provider. Users who authenticate exclusively through Google OAuth cannot log in at all. The error they see — a browser SSL warning on a redirect URL — is confusing and alarming, and the support volume per affected user is high.
OAuth callback URLs are typically on the main app domain or API subdomain, so they are usually covered by the certificate on that domain. The risk is a multi-tenant architecture where OAuth callbacks are on per-tenant subdomains.
Multi-Tenant Custom Domains
The most complex SSL scenario for SaaS agencies is a product that allows the client's customers to use their own custom domain. A project management tool might allow customers to access it at work.theircompany.com instead of acmecorp.clientproduct.com. A white-label SaaS might provision a fully custom domain for each customer at signup.
Each custom domain in a multi-tenant system requires its own SSL certificate, typically provisioned automatically via Let's Encrypt or a cloud provider's certificate management service. The provisioning happens at the platform level — often via Cloudflare for SaaS, AWS Certificate Manager, or a custom ACME client. But the renewal and integrity of each certificate still depends on the CNAME delegation that the end customer controls in their own DNS.
When an end customer migrates their DNS provider and breaks their CNAME delegation, their custom domain stops working. Their SSL certificate renewal fails at the next cycle. The SaaS agency is responsible for the platform's certificate management, but the CNAME break is on the customer's side. Without monitoring the custom domain CNAME, the agency has no visibility into the break until the customer reports it.
What to Monitor and Why
Minimum coverage for a SaaS product
API subdomain — most critical. Expiry takes down every API client simultaneously. Monitor for expiry 30 days out and for CNAME integrity if the API subdomain uses a CDN.
App subdomain — if the frontend and API are on separate subdomains. The frontend certificate failing takes down the user-facing application.
Webhook endpoints — if on a separate subdomain from the API. If on the same subdomain as the API, they're covered by the API certificate.
OAuth callback URLs — verify they share a certificate with the app or API subdomain. If they're on a separate domain or subdomain, add them explicitly.
Marketing domain — the lowest-priority certificate for a SaaS product, but still worth monitoring. A lapsed marketing certificate erodes trust with prospects.
If you have multi-tenant custom domains
Add a sample of customer custom domains to your monitoring. You cannot monitor every custom domain at scale with a standard monitoring tool — multi-tenant certificate management at scale requires infrastructure-level tooling. But monitoring a representative sample lets you catch systemic CNAME or certificate renewal failures before they affect all customers.
For per-customer CNAME drift specifically, the right signal is monitoring the CNAME record target — not just whether the domain resolves. If 5% of your sampled customer domains have CNAME targets that no longer match the expected value, you have a platform-level problem that will surface gradually across the customer base.
The Failure Pattern SaaS Agencies Miss Most
The failure pattern that agency SSL monitoring most often misses for SaaS products is partial outage with intact marketing site.
Standard uptime monitoring checks a URL and reports up or down. For a SaaS product, the marketing site at clientproduct.com is almost always up — it's a static or CDN-served page with its own certificate. The API at api.clientproduct.com, the webhook endpoint, and the OAuth callback are on separate subdomains with separate certificates. A monitoring tool checking clientproduct.com reports green while every authenticated user experiences SSL errors on every API call.
The fix is monitoring each subdomain as a separate asset, not monitoring the product as a single URL. Each subdomain carries its own certificate with its own expiry date, and each one is an independent failure point.
Setting Up SSL Monitoring for a SaaS Client
When you take on a SaaS product as an agency client, the SSL audit at project start should produce a list of every HTTPS endpoint the product exposes:
- Marketing domain (www and apex)
- App subdomain
- API subdomain
- Any separate webhook subdomain
- Admin or internal subdomains
- Staging and UAT environments
- Any OAuth callback URLs on distinct subdomains
Add each to your monitoring tool as a separate asset. Set expiry alerts to 30 days for production endpoints and 14 days for staging. Set CNAME integrity monitoring for any subdomain that uses a CDN or cloud platform for SSL — the CNAME break is usually the precursor to a certificate renewal failure, and it fires weeks before expiry.
For multi-tenant products with custom domains, identify the mechanism — Cloudflare for SaaS, ACM, or custom ACME — and verify that the renewal process is functioning by monitoring a small set of customer domains as a health check.
The goal is to find out about certificate problems from your monitoring tool, not from the client's customers.