Monitoring Webflow Client Sites for Agencies: SSL, DNS, and Custom Domain Failures

Webflow is now the platform of choice for a large segment of design-led agencies. Its visual editor, hosting model, and CMS capabilities make it straightforward to build and hand off polished sites to clients. The hosting arrangement, however, creates a monitoring surface that is different from WordPress or self-hosted setups — and most generic monitoring tools do not account for those differences.

This post covers what Webflow agencies need to monitor, where failures actually occur, and why the structure of Webflow's custom domain setup matters for how you configure alerts.

How Webflow Hosting Works (and Why It Matters for Monitoring)

When a client connects a custom domain to a Webflow site, the DNS configuration required is a CNAME record pointing to proxy-ssl.webflow.com. Webflow handles SSL provisioning automatically via Let's Encrypt and serves the site through its own CDN.

That arrangement has two monitoring implications:

SSL is managed by Webflow, not by you. You do not renew the certificate. Webflow does. If something goes wrong with Webflow's certificate provisioning — Let's Encrypt rate limits, misconfigured domain verification, a Webflow infrastructure issue — the SSL error surfaces on your client's domain and the client calls you.

DNS is managed by whoever holds the domain registrar. This is often the client, a previous agency, or a registrar the client has largely forgotten about. If the CNAME record is changed, removed, or overwritten during a registrar migration, the site goes down. Webflow's dashboard shows the site as published. The external monitoring problem is invisible to Webflow.

What Breaks on Webflow Client Sites

1. CNAME drift after domain migrations

The most common Webflow-specific failure mode: a client migrates their domain from one registrar to another, the DNS records are not carried over accurately, and the CNAME to proxy-ssl.webflow.com disappears. The site goes offline. Webflow's own dashboard shows no error because from Webflow's perspective, the site is published.

This is a pure DNS monitoring problem. If you are checking DNS records for changes on client domains, you catch this before anyone notices. If you are only doing HTTP uptime pings, you catch it when the site is already down.

2. SSL certificate provisioning failures

Webflow provisions SSL certificates via Let's Encrypt when a custom domain is connected. If there is a misconfiguration — incomplete DNS propagation when the domain was connected, a residual CAA record blocking Let's Encrypt, or a Webflow platform issue during renewal — the certificate may fail to renew.

Let's Encrypt certificates expire after 90 days. Webflow attempts renewal automatically, but the failure modes are opaque. External SSL certificate expiry monitoring catches a certificate that failed to renew before the browser warning appears.

3. www vs. root domain misconfiguration

Webflow requires both www and the root domain to be configured, but the configuration method differs: the root domain typically requires an A record pointing to Webflow's IP, while the www subdomain uses the CNAME. Agencies frequently encounter client sites where one of the two was set up correctly and the other was not, or where a root domain A record is pointing to a stale IP from a previous host.

This creates a half-working state: one URL returns a 200, the other returns a connection error or redirects incorrectly.

4. Webflow platform incidents

Webflow has had platform-level incidents that affected SSL, CDN, and publishing across all hosted sites. During these incidents, the individual site owner cannot do anything — but they do receive client calls.

Vendor status monitoring on Webflow's own status page means you know before your clients do, which changes the client communication from reactive ("I have no idea what's happening") to proactive ("Webflow is experiencing a platform incident — here is what we know so far").

What to Monitor on Webflow Client Sites

SSL certificate validity and expiry Even though Webflow manages the certificate, you should be monitoring expiry dates from the outside. If Webflow's auto-renewal fails for any reason, you want to know 30+ days before expiry, not the day the browser warning appears.

DNS record presence and value The CNAME from the client's domain to proxy-ssl.webflow.com should remain stable. Any change to that record warrants immediate investigation. The root domain A record should also be verified on setup and monitored for drift.

HTTP uptime on both www and root domain Both the www subdomain and the bare domain should resolve and return expected status codes. Many Webflow sites redirect one to the other — verify the redirect chain is intact and not returning unexpected codes.

Webflow platform status Webflow publishes status information at their status page. Monitoring vendor status for Webflow alongside client-specific monitoring means you have the full picture when something goes wrong.

What Generic Monitoring Tools Miss on Webflow

Most uptime monitors check a single URL for HTTP 200 responses. They do not:

Monitor the DNS record structure, so they miss CNAME drift until the site is already down
Monitor SSL certificate metadata, so they miss a certificate approaching expiry
Distinguish between a site-level failure and a platform-level Webflow incident
Route alerts per client, which means your internal team alert and a client-facing notification go to the same place

The gap matters at portfolio scale. An agency managing 30 Webflow clients with a generic uptime tool has 30 HTTP pings and no DNS or SSL visibility. The first sign of most Webflow-specific failures is a client call.

Setting Up Webflow Agency Monitoring

The practical setup for Webflow agencies:

For each client domain, add an asset and configure SSL monitoring. Set the expiry threshold to alert at 30 days — Webflow renews well before that, but the gap shows you when renewal has failed.
Enable DNS change monitoring on the root and www records. Any change to either should trigger an alert to your internal team.
Add Webflow as a vendor in your vendor monitoring setup so you get platform status updates without checking manually.
Configure client-specific alert channels so when a Webflow issue affects one client, the alert routes to the team responsible for that client — not to a shared inbox watched by everyone.

If you are managing a large Webflow portfolio, a monitoring setup like this catches most failures before clients notice them, and gives you context when they do.

The Agency Responsibility Question

Whether your agency is responsible for a Webflow SSL or DNS failure depends on what was agreed at contract time. Most Webflow agencies do not explicitly sell monitoring — they sell builds and optionally ongoing maintenance.

The practical issue is that when a client site goes down, they call you regardless of what the contract says. Having monitoring in place means you know before they call, you have a record of the failure timeline, and you can show the client what happened and when. That changes the client conversation from a blame-assignment exercise to a problem-resolution exercise.

Merlonix is built for agency portfolio monitoring — SSL expiry alerts, DNS change detection, vendor status monitoring, and per-client alert routing. Start a free trial and add your first Webflow client domain.