Monitoring Craft CMS Client Sites for Agencies: SSL, DNS, and Self-Hosted Failure Modes

Craft CMS is a developer-focused, self-hosted CMS that attracts agencies doing technically sophisticated work: custom e-commerce, headless content delivery, multi-channel publishing, and enterprise web applications. It is not a managed platform — it runs on servers the agency or client controls, which means SSL certificate management, DNS configuration, and infrastructure maintenance are all within the agency's scope of responsibility.

This is a different monitoring challenge from agencies working with hosted platforms like Webflow, Squarespace, or Kajabi. On those platforms, the platform manages SSL provisioning and the agency monitors the SSL outcome. On Craft CMS, the agency manages the SSL process itself — certbot configuration, renewal cron jobs, web server reload hooks, and CA trust chains. When any part of that process breaks, the failure is invisible until the certificate expires.

This post covers the SSL and DNS failure modes specific to self-hosted Craft CMS deployments and what a monitoring setup looks like for a Craft agency portfolio.

How Craft CMS Deployments Handle SSL

Most Craft CMS sites on VPS or dedicated hosting use one of three SSL management approaches:

Certbot with Let's Encrypt: The most common approach for agencies running Nginx or Apache on a VPS. Certbot installs, runs the ACME challenge to verify domain ownership, and sets up a cron job or systemd timer to renew certificates automatically before they expire.

Caddy: An alternative web server that handles HTTPS natively using Let's Encrypt, with automatic certificate provisioning and renewal without manual certbot configuration.

Commercial SSL certificates: Some enterprise Craft CMS clients use DV, OV, or EV certificates from commercial CAs (DigiCert, Sectigo, GlobalSign), typically managed through a control panel or purchased annually.

Each approach has a different failure mode. Certbot fails silently when the renewal cron runs as the wrong user, when the challenge path is not served by the web server, or when the Nginx reload hook is not wired to the certbot post-renewal hook. Caddy fails when firewall rules block the ACME challenge. Commercial certificates fail when the renewal reminder is missed and the certificate is not replaced before expiry.

The Failure Modes to Watch

1. Let's Encrypt renewal breaks silently after server changes

Certbot renewal is typically set up once, during the initial server configuration, and then left to run automatically. The failure mode is that the renewal process breaks after server configuration changes — and the break is invisible until the certificate expires 90 days later.

Common scenarios where certbot renewal breaks silently:

PHP-FPM socket path changes: After a PHP version upgrade (e.g., PHP 8.1 to 8.2), the PHP-FPM socket path changes. Certbot's webroot renewal method depends on serving the ACME challenge from a specific directory. If the web server configuration is updated for the new PHP socket but the challenge directory path is not preserved, the next renewal attempt fails.
Nginx configuration restructuring: After a major site refactor or migration, Nginx configuration files are reorganized. The location block that served certbot's .well-known/acme-challenge/ directory is removed or placed in a block that is not served in the new configuration. The renewal fails, the old certificate continues serving, and the failure is logged in certbot's log that no one reads.
Server migration: When a Craft CMS site migrates to a new server — PHP upgrade, host switch, infrastructure update — certbot is reinstalled and configured on the new server, but the cron job does not run correctly (wrong user permissions, path not in cron environment, systemd timer not enabled) and renewal fails silently.

What to monitor: SSL certificate expiry with 30-day alerts, and full certificate chain validation on every check interval. A broken renewal process is visible before expiry: certbot renews the certificate but the web server is not reloaded, so the old certificate continues serving despite a new certificate existing on disk. That chain change fires an alert.

2. CAA record conflicts block re-issuance from Let's Encrypt

CAA (Certification Authority Authorization) records are DNS records that specify which certificate authorities are permitted to issue certificates for a domain. They are set by the domain owner at the registrar or DNS provider.

When a Craft CMS client migrates from a commercial SSL certificate (DigiCert, Sectigo) to Let's Encrypt — often done when a site migrates to self-hosted infrastructure — CAA records may still restrict issuance to the previous CA. Let's Encrypt's ACME challenge completes (the domain is reachable and certbot can place the challenge file), but the CA check fails because the CAA record does not permit Let's Encrypt as an issuer.

The certbot error is logged: CAA record for clientdomain.com prevents issuance by Let's Encrypt. No alert is sent. The existing commercial certificate continues serving until it expires. When it does expire, no replacement certificate can be issued until the CAA records are updated.

What to monitor: DNS record monitoring for CAA records, in addition to SSL expiry. When CAA records change — added, modified, or removed — the alert fires immediately, giving the agency visibility into CA authorization changes before they affect renewal.

3. Multi-environment subdomain SSL gaps

Craft CMS agencies typically manage multi-environment configurations for client sites:

clientdomain.com — production
staging.clientdomain.com — staging environment for content review
dev.clientdomain.com — development environment (sometimes client-accessible)
api.clientdomain.com — API endpoint for headless or decoupled front-ends

Each environment has its own SSL certificate and its own renewal process. When a server migration is applied to production but not staging, the staging environment's SSL renewal process may break independently. When the API subdomain runs on a different server or has its own certbot configuration, its renewal can fail without affecting production.

Multi-environment failures are particularly damaging because they are easy to miss: production stays up and passes any monitoring check, so the SSL failure on staging or the API subdomain is invisible until a developer or client notices a browser warning.

What to monitor: Every subdomain in the client's Craft CMS configuration — not just the production domain. Staging, dev, and API subdomains all need SSL chain monitoring. Failures on non-production environments still damage client confidence in the agency's technical competence.

4. CDN proxy layer SSL breaks

Many Craft CMS production deployments proxy through Cloudflare or a CDN layer. The CDN handles the edge certificate — the certificate that browsers see — and proxies requests back to the origin server. This creates two SSL layers: the edge certificate (CDN-managed) and the origin certificate (certbot-managed on the server).

When the CDN proxy is removed, changed, or misconfigured — a Cloudflare orange-cloud toggle turned off, a CDN service misconfiguration — browsers connect directly to the origin server. If the origin server's certbot-managed certificate covers the right domain, the connection still works. If the origin certificate is a wildcard, self-signed, or expired certificate that was hidden behind the CDN layer, the connection fails immediately.

What to monitor: DNS record changes for CNAME records pointing to CDN infrastructure. When a CDN proxy layer changes — CNAME target changes, A record swap — the alert fires within minutes, giving the agency visibility before end users connect directly to origin.

What a Craft CMS Agency Monitoring Setup Covers

An effective monitoring setup for a Craft CMS agency portfolio has four layers:

SSL chain validation for every environment: Full certificate chain monitoring for production, staging, dev, and API subdomains — not just the main domain. Alerts fire immediately on any chain validation failure, and expiry alerts fire 30 days ahead.

DNS record monitoring including CAA: DNS record integrity for A records, CNAME records, and CAA records. CAA record changes are particularly important for Let's Encrypt deployments where CA authorization can block re-issuance silently.

CDN proxy layer monitoring: CNAME record monitoring for subdomains proxied through CDN infrastructure. When a proxy configuration change exposes the origin server's certificate directly to browsers, the DNS layer change fires an alert before end users encounter the failure.

Domain expiry tracking: For client-controlled domain registrations, expiry date monitoring with 30-day alerts. Craft CMS clients often control their own domain registrations independently of the agency's server and SSL management.

Why Standard Uptime Monitoring Is Insufficient for Craft CMS

HTTP uptime monitoring checks whether a URL returns a 200 response. For self-hosted Craft CMS deployments, this misses the most consequential failure modes:

A certbot renewal failure 20 days from expiry passes HTTP uptime checks but will take the site down when the certificate expires
A CAA record conflict blocking Let's Encrypt re-issuance is invisible to HTTP monitoring
A CDN proxy layer change that exposes a self-signed origin certificate passes HTTP uptime checks until a browser with strict certificate validation rejects the connection

The failure modes that create client support calls for Craft CMS agencies are SSL and DNS failures — not HTTP failures. Monitoring those layers specifically, across every environment subdomain in the client's configuration, is what gives the agency visibility before clients notice.

How Merlonix Covers Craft CMS Agency Portfolios

Merlonix is designed for agencies managing self-hosted CMS deployments where the SSL and DNS lifecycle is directly owned by the agency. Adding a client domain takes under two minutes: DNS TXT record verification, then full SSL chain monitoring and DNS record monitoring starts automatically for the apex domain and any added subdomains.

Full chain validation fires before expiry and immediately on any chain change. CAA record changes fire when DNS records are updated. CDN CNAME changes fire within minutes of propagation. Domain expiry alerts fire 30 days ahead of the expiry window.

Start a free trial and add your first Craft CMS client domain.