Monitoring Framer Client Sites for Agencies: SSL, DNS, and Custom Domain Failures
Framer has become a go-to site builder for design-led agencies. Its component model, real-time collaboration, and built-in CMS make it genuinely compelling for agencies producing marketing sites and campaign landing pages at speed. But the same infrastructure that makes Framer fast to build on introduces specific failure modes that agencies managing client portfolios need to monitor — and that standard uptime tools miss.
This post covers the failure patterns specific to Framer client sites and how to set up monitoring that catches them before clients do.
How Framer Handles Custom Domains and SSL
When a client connects a custom domain to a Framer site, two things happen simultaneously: DNS propagation and SSL provisioning.
Framer uses its own CDN infrastructure to serve published sites. SSL certificates are provisioned and managed by Framer on behalf of the domain. This is convenient — the agency does not need to manage certificate renewals — but it creates a failure surface that is out of the agency's direct control.
The provisioning process requires the client's DNS to be correctly configured to point to Framer's infrastructure. If the DNS is configured using Framer's recommended nameservers, the process is mostly automatic. If the client uses external nameservers and creates CNAME or A records pointing to Framer's edge, the provisioning is more sensitive to how those records are configured.
The critical failure mode: SSL provisioning can stall silently. The domain resolves, the Framer site loads, and a certificate error appears in some browsers or for some visitors — while a basic uptime monitor reports a 200 OK because it only checks the HTTP response code, not the certificate validity.
The Failure Modes to Watch
1. SSL provisioning failure after custom domain connection
The most common Framer SSL failure happens immediately after a client connects a new custom domain. If the DNS configuration is slightly off — a missing CAA record conflict, an incorrect CNAME target, or a delay in DNS propagation — Framer's SSL provisioning can fail or stall.
The result is a domain that resolves to the Framer site but serves an invalid or incomplete certificate. HTTP uptime monitoring will not catch this. SSL certificate monitoring that validates the full certificate chain will.
What to monitor: Certificate validity, chain completeness, and issuer identity — checked independently of HTTP response codes.
2. DNS drift after domain transfer or registrar migration
Framer clients frequently transfer domains between registrars as their business evolves, or they switch from using Framer nameservers to managing DNS externally (or vice versa). Both transitions can silently overwrite the DNS records that Framer requires.
A client who moves their domain from Namecheap to Cloudflare and asks the registrar to handle the nameserver migration may not realize that the migration reset their Framer-required CNAME. The site goes down or shows a certificate error. The agency finds out from the client.
What to monitor: CNAME and A record values for custom domains. An alert on first change is enough — you can review whether the new record is correct or a misconfiguration.
3. Framer platform incidents affecting multiple client sites
Framer's CDN infrastructure serves all Framer-published sites. A CDN degradation, authentication service issue, or media serving problem at Framer's infrastructure level can affect dozens or hundreds of client sites simultaneously.
The distinction between a Framer platform incident and a client-specific DNS misconfiguration matters operationally. If 10 of your client sites are showing errors at the same time, the correct response is to check Framer's status page and communicate to clients that you are aware and monitoring — not to start diagnosing each domain independently.
What to monitor: A vendor status monitor for Framer's platform, alongside individual domain checks, lets you distinguish a Framer-wide incident from a client-specific failure within seconds.
4. Domain expiry during client handoffs
Design agencies frequently build sites for clients and then hand off domain management to the client. When the handoff is informal — the client receives login credentials but the agency's contact is still on the domain registrar account — domain renewals can fall through the gap.
A domain that expires after a handoff takes the Framer site completely offline, including any active SSL certificates. This failure is entirely preventable with domain expiry monitoring.
What to monitor: Domain registration expiry date, with a 30-day alert threshold. This catches the impending expiry with enough time to resolve the handoff ambiguity before anything goes down.
What a Framer Monitoring Setup Looks Like
An effective monitoring setup for a Framer client portfolio covers four layers:
SSL certificate monitoring: Checks the certificate chain end-to-end on every check interval — not just whether the domain is live. Fires 30 days before expiry and immediately on certificate change or chain invalidation.
DNS record monitoring: Watches the CNAME or A records that point the custom domain to Framer's infrastructure. Fires immediately on any record change, regardless of whether that change causes visible downtime.
HTTP uptime monitoring: Basic availability check on the expected response code and, optionally, a content keyword. Catches full outages and misconfigured redirects.
Vendor status monitoring: Tracks Framer's platform status page so that infrastructure-level incidents are surfaced alongside per-domain alerts. Lets you distinguish "one client's DNS broke" from "Framer is having an incident."
Domain expiry monitoring: Watches registration expiry dates across your entire client portfolio. Fires at 30 and 14 days before expiry.
Why Standard Uptime Tools Miss Framer Failures
The Framer failure modes listed above share a common characteristic: they occur at the infrastructure layer below HTTP. An uptime tool that checks https://clientsite.com and verifies a 200 response will:
- Report green when SSL provisioning has stalled but the domain still resolves
- Not alert when a CNAME is changed unless the site goes offline as a result
- Not distinguish a Framer platform incident from a site-specific issue
- Not track domain registration expiry at all
Agencies using standard uptime monitoring on Framer client sites have a gap between what the monitor reports and what clients actually experience. The gap closes when monitoring covers SSL validity, DNS records, and domain expiry independently from HTTP availability.
How Merlonix Covers Framer Client Sites
Merlonix is designed for agencies managing client portfolios across different platforms. Adding a Framer client domain takes under two minutes: DNS TXT record verification, then SSL and DNS monitoring starts automatically.
Each client's domains are organized under their client account — alerts, reports, and API access are separated per client. When a Framer SSL provisioning failure occurs, the alert includes the domain, the specific certificate field that failed validation, and the timestamp of first failure. When a DNS record changes, the alert fires within minutes — before any resulting downtime, with the previous and new record values in the alert body.
Framer platform incidents appear in your vendor status feed, surfaced separately from per-domain alerts so you can communicate accurately to affected clients from the moment the incident starts.
Start a free trial and add your first Framer client domain.
→ Related: Webflow Agency Monitoring → Related: Squarespace Agency Monitoring → Related: Wix Agency Monitoring → Related: What Causes DNS Record Drift → Related: Client Domain Expired: What to Do