Monitoring Ghost Client Sites for Agencies: SSL, DNS, and Let's Encrypt Failures

Ghost has established itself as the publishing platform of choice for agencies running newsletters, content sites, and membership publications for clients. Its clean editor, native members and payments support, and headless API make it a compelling alternative to WordPress for content-forward clients. But Ghost's infrastructure — particularly its dependency on Let's Encrypt for SSL and its CDN architecture for Ghost(Pro) — introduces failure modes that agencies managing client publications need to monitor proactively.

This post covers the failure patterns specific to Ghost client publications and the monitoring setup that catches them before clients do.

How Ghost Handles SSL and Custom Domains

Ghost supports custom domains for both Ghost(Pro) (the hosted platform) and self-hosted instances. SSL certificate management differs between the two.

Ghost(Pro): Ghost provisions and manages SSL certificates automatically for publications on its hosted platform. When a client connects a custom domain, Ghost handles the certificate issuance via Let's Encrypt. The agency has no direct control over this process.

Self-hosted Ghost: SSL is managed by the web server layer (typically Nginx or Caddy) using Let's Encrypt certbot or a similar tool. The renewal process runs as a scheduled job on the server. If the server's DNS records change or CAA records from a previous certificate authority conflict with Let's Encrypt, renewals fail silently.

In both cases, the failure surface is similar: SSL certificate renewal can break after a DNS change without producing visible downtime. The publication continues to serve content over HTTP while the certificate ages toward expiry or renewal fails outright.

The Failure Modes to Watch

1. Let's Encrypt renewal failure after DNS migration

The most common Ghost SSL failure in agency portfolios happens after a DNS migration. When you move a client's publication to a new hosting provider, change nameservers, or update A records as part of a platform switch, Let's Encrypt's renewal challenge can lose its path to verification.

Let's Encrypt uses either HTTP-01 (placing a file at a specific URL) or DNS-01 (adding a TXT record) to verify domain ownership before issuing or renewing a certificate. After a DNS migration, the verification path may no longer work as expected — particularly if the migration changes the IP address that Let's Encrypt expects to reach or disrupts the DNS record that DNS-01 challenges rely on.

The failure is silent. The certificate remains valid until its next renewal attempt. When that attempt fails, the certificate expires. The publication goes from serving a valid certificate to serving an expired one with no intervening warning if you are only monitoring HTTP availability.

What to monitor: Certificate expiry date (with a 30-day alert threshold) and certificate chain validity — checked independently on every monitoring interval. An expiry alert fires with enough time to diagnose and fix the renewal path.

2. CAA record conflicts after agency transitions

Clients who switch agencies frequently have DNS records set up by their previous agency that conflict with Let's Encrypt. CAA (Certification Authority Authorization) records specify which certificate authorities are permitted to issue certificates for a domain.

If a previous agency configured CAA records restricting issuance to a specific CA (DigiCert, Sectigo, or another commercial CA), and the new setup relies on Let's Encrypt, certificate issuance will fail — silently, until the next renewal attempt.

CAA record conflicts are nearly invisible during the transition because the existing certificate (issued by the previously permitted CA) continues to be served. The failure only surfaces at renewal time, which can be 60–90 days after the migration.

What to monitor: CAA record changes — any modification to CAA records should trigger an alert so the agency can verify the new configuration permits the CA the publication depends on.

3. Ghost(Pro) platform incidents affecting the entire client roster

Agencies managing multiple Ghost(Pro) publications are dependent on Ghost's infrastructure. A CDN degradation, DNS resolution issue, or certificate authority incident at Ghost's infrastructure level can affect all hosted publications simultaneously.

The operational distinction matters: a client calling about their publication being down during a Ghost(Pro) incident requires a different response than a client calling about a DNS misconfiguration specific to their domain. Having vendor status monitoring that surfaces Ghost(Pro) incidents in real time lets you respond accurately from the first symptom.

What to monitor: Ghost platform status, alongside individual domain SSL and DNS checks. When a Ghost(Pro) incident is active, the vendor feed surfaces it separately from per-publication alerts.

4. DNS record drift on self-hosted publications

Self-hosted Ghost publications require specific DNS records to be maintained correctly — A records pointing to the server IP, and in some cases CNAME records for subdomain publications. When a hosting provider migrates servers, changes IP allocations, or when a client updates their DNS without informing the agency, those records drift.

The failure mode is identical to any DNS drift scenario: the publication continues serving from the cached DNS response until the TTL expires, then starts failing. The window between the DNS change and the visible failure can be anywhere from minutes to 48 hours depending on TTL values.

What to monitor: A and CNAME record values for all self-hosted publications. Any first change fires an alert — regardless of whether the change causes immediate downtime.

What a Ghost Monitoring Setup Looks Like

An effective monitoring setup for a Ghost agency portfolio covers four layers:

SSL certificate monitoring: Validates the full certificate chain — expiry date, issuer, chain completeness, and domain match — on every check interval. Fires 30 days before expiry and immediately on certificate change or chain break. Catches Let's Encrypt renewal failures before they produce browser warnings.

DNS record monitoring: Watches A, CNAME, and CAA records for each publication. Fires immediately on any record change. Catches CAA conflicts, post-migration DNS drift, and self-hosted server IP changes.

HTTP uptime monitoring: Basic availability check. Catches full outages, redirect loops, and publication configuration errors that prevent the Ghost instance from serving responses.

Vendor status monitoring: Tracks Ghost(Pro) platform status so infrastructure incidents are surfaced alongside per-domain alerts. Lets you distinguish a Ghost CDN incident from a publication-specific configuration issue within seconds.

Why Standard Uptime Tools Miss Ghost Failures

Ghost's failure modes share a common characteristic: they occur at the certificate and DNS layer, not the HTTP layer. An uptime tool checking https://clientpublication.com and verifying a 200 response will:

Report green when Let's Encrypt renewal has failed but the current certificate has not yet expired
Not alert when a CAA record has been added that will block the next renewal attempt
Not distinguish a Ghost(Pro) platform incident from a publication-specific issue
Not detect a DNS record change until it causes a full outage

Agencies using HTTP-only uptime monitoring on Ghost client publications have a gap between what the monitor reports and what clients experience. The gap closes when monitoring covers SSL chain validity, DNS record state, and certificate expiry with enough lead time to act.

How Merlonix Covers Ghost Client Publications

Merlonix is designed for agencies managing client portfolios across different CMS platforms. Adding a Ghost client publication takes under two minutes: DNS TXT record verification, then SSL and DNS monitoring starts automatically — whether the publication is on Ghost(Pro) or self-hosted.

Each client's publications are organized under their client account. When a Let's Encrypt renewal failure is detected, the alert includes the publication domain, the specific chain validation failure, and the certificate expiry date. When a DNS record changes, the alert fires within minutes — before any resulting downtime — with the previous and new record values included.

Ghost(Pro) platform incidents appear in your vendor status feed, separate from per-publication alerts, so you can communicate accurately to affected clients from the moment the incident is confirmed.

Start a free trial and add your first Ghost client publication.

→ Related: Framer Agency Monitoring → Related: Webflow Agency Monitoring → Related: SSL Monitoring for WordPress Agencies → Related: What Causes DNS Record Drift → Related: How to Audit Client SSL Certificates