App Platform managed certs fail silently when the CNAME points at a Droplet IP from your previous deployment.
The app serves the old-deployment cert. Browsers reject it. The DigitalOcean dashboard says everything is fine.
DigitalOcean agencies running App Platform, Droplets with Certbot, and Spaces with CDN endpoints deal with App Platform managed certs that silently fail when the CNAME points at the wrong target after a Droplet-to-App-Platform migration, Droplet Certbot renewals dying silently after a resize blocks port 80, and Spaces CDN custom domains where the CNAME points at the region endpoint instead of the CDN endpoint. Merlonix monitors every DigitalOcean-attached subdomain so the wrong-cert and renewal-failure modes surface before clients see browser warnings.
No credit card for the trial. Cancel any time.
- Check cadence (Agency)
- 5 min
- SSL pre-expiry alert
- 30 days
- Independent DNS resolvers
- 3
- Vendors watched
- 11
Where DigitalOcean agencies get caught out
Three failure modes specific to DigitalOcean deployments with App Platform managed certs, Droplet Certbot renewal cron jobs, and Spaces CDN custom-domain CNAME configuration.
DigitalOcean agencies deal with App Platform managed certs silently failing because the CNAME points at the Droplet IP or an old deployment target instead of the current <app>.ondigitalocean.app target (App Platform serves the previous-deployment cert; browsers reject it), Droplet Certbot renewals dying silently after a Droplet resize live-migration breaks the cron daemon or post-install firewall rules block port 80 (no platform alert — the cert expires 90 days later), and Spaces CDN custom domains where the CNAME is pointed at the region endpoint instead of the CDN endpoint (bucket returns content correctly but with a wrong-host cert).
App Platform managed SSL certificates require the CNAME to point at the current <app-name>.ondigitalocean.app target. After a Droplet-to-App-Platform migration, agencies often forget to update the CNAME — it still points at the old Droplet IP or an earlier App Platform deployment target. App Platform serves the previous deployment's cert (which doesn't match the new hostname); browsers reject it. The DigitalOcean dashboard shows the new deployment as healthy because health checks pass on the .ondigitalocean.app endpoint, masking the custom-domain cert mismatch
A DigitalOcean agency migrates a client product from a Droplet running Nginx + Certbot to App Platform for managed deploys. The Droplet had a Let's Encrypt cert for app.client.com that renewed via Certbot. The agency engineer deploys the app to App Platform, points the CNAME for app.client.com at the new <app-name>.ondigitalocean.app target, and confirms the DigitalOcean dashboard shows the deployment healthy. But the CNAME update was made at the registrar level on a domain whose authoritative nameserver TTL was 24 hours — global propagation hadn't completed when App Platform tried to provision the managed cert. App Platform's cert request failed silently; the app falls back to serving the previous-deployment cert from cache. Browsers throw cert-mismatch warnings
A DigitalOcean agency operates a client B2B SaaS that has been running on a $20/month Droplet with Nginx and Certbot for two years. The agency wants to move to App Platform for managed deploys, auto-scaling, and zero-downtime releases. The migration plan: deploy the app to App Platform first, point the CNAME at the new target, verify, then tear down the Droplet. The agency engineer deploys the app successfully to App Platform — the new deployment is reachable at merlonix-saas.ondigitalocean.app and the DigitalOcean dashboard shows healthy. The engineer updates the CNAME for app.client.com to point at merlonix-saas.ondigitalocean.app at the client's registrar. The registrar nameserver TTL was 24 hours from a configuration choice made years ago; the engineer doesn't notice. App Platform attempts to provision a managed cert for app.client.com via Let's Encrypt within minutes of the CNAME being added. The validation query against app.client.com still resolves to the old Droplet IP because global DNS propagation is taking hours. The cert request fails. App Platform retries silently every 6 hours, each retry hitting the partially-propagated DNS state. The app continues to serve the previous-deployment cert (from cache or the platform default) when requests come in for app.client.com. Browsers throw cert-mismatch warnings. The DigitalOcean dashboard shows the App Platform deployment as healthy because the health check uses the .ondigitalocean.app endpoint, not the custom domain. The agency engineer assumes the cert provisioning is in progress and waits — but the actual failure surfaces only when a customer reports the cert warning ~3 hours later. The fix requires manually triggering cert reprovisioning after DNS propagation completes; the silent-failure window was hours.
Droplets running Certbot have no platform-level renewal alerting — DigitalOcean doesn't monitor the renewal cron job. When the Droplet is resized (live migration moves the VM to a new host) the cron daemon may not restart cleanly, or post-install firewall rules can block port 80 needed for Let's Encrypt HTTP validation. The cert renewal stops silently. The agency only discovers the failure when the cert expires 90 days later and the site starts serving browser warnings
A DigitalOcean agency manages a client product on a Droplet with Certbot configured to renew automatically via a cron job. The client requests resizing the Droplet from $20/month to $40/month to handle increased traffic. The agency engineer initiates the resize via the DigitalOcean dashboard — the Droplet is live-migrated to a new host. The resize completes; the engineer confirms the site is responding. The Certbot cron job, however, didn't restart cleanly after the live migration. The next renewal attempt fails because the cron service isn't running. There's no DigitalOcean platform alert for this — Certbot renewal is the agency's responsibility, not DigitalOcean's. 60 days later, the cert expires and the site starts serving browser warnings
A DigitalOcean agency manages a client product running on a $20/month Droplet with Nginx, PHP-FPM, and Certbot configured for the apex domain and three subdomains. Certbot was set up via certbot-auto two years ago; the cron job runs daily at 3:00 AM and successfully renews each cert ~85 days into its 90-day validity window. The client requests more capacity for an upcoming launch event; the agency engineer resizes the Droplet from 1GB/$20 to 4GB/$40 via the DigitalOcean dashboard. The resize triggers a live migration: the VM is moved to a new physical host, the disk image is copied, the network configuration is restored. The migration takes ~3 minutes and the site continues to serve traffic throughout. After the migration, the engineer confirms the site is responding to HTTP requests and considers the resize complete. The Certbot cron job, however, was running under a system user whose cron daemon didn't restart cleanly after the live migration — the kernel-level cron timers were lost and the system wasn't restarted to re-initialize them. The renewal cron entry exists in /etc/cron.d/certbot but the cron daemon itself isn't firing it. No alert surfaces — DigitalOcean doesn't monitor Certbot, and the agency's monitoring stack (configured years ago when Certbot was working) doesn't check the certbot service status either. The current cert is valid for ~25 more days. 25 days pass. The cert expires. The site starts serving an expired cert; browsers throw cert errors. The agency engineer SSH into the Droplet, runs certbot renew manually, gets a success message, and the site recovers. But the failure mode — cron daemon not restarting after a live migration — is invisible in the audit log because no one was watching for it.
DigitalOcean Spaces CDN custom domains use a separate cert-issuance path from the underlying Spaces bucket. Agencies often configure the CNAME pointing at the Spaces region endpoint (e.g., nyc3.digitaloceanspaces.com) rather than the CDN endpoint (e.g., nyc3.cdn.digitaloceanspaces.com). The bucket returns content but with a wrong-host cert; browsers throw cert warnings. The agency engineer sees content arriving correctly and doesn't look at the cert until a customer reports the browser warning
A DigitalOcean agency configures a Spaces CDN endpoint at cdn.client.com for serving client static assets. The agency engineer enables the CDN on the Spaces bucket, sets the custom domain, and points the CNAME for cdn.client.com. The agency engineer types the CNAME target as nyc3.digitaloceanspaces.com (the region endpoint) instead of <region>.cdn.digitaloceanspaces.com (the CDN endpoint). The bucket returns content correctly because the region endpoint serves the bucket directly, but the cert presented is for *.digitaloceanspaces.com — not cdn.client.com. Browsers throw cert warnings on every request
A DigitalOcean agency operates a client e-commerce product where product images are served from a DigitalOcean Spaces bucket at media-bucket.nyc3.digitaloceanspaces.com. The agency wants to serve images via a branded CDN endpoint at cdn.client.com. The agency enables the Spaces CDN feature on the bucket, configures the CDN's custom domain as cdn.client.com, and is told by the DigitalOcean dashboard to add a CNAME for cdn.client.com. The agency engineer adds the CNAME at the client's registrar; the target field gets nyc3.digitaloceanspaces.com (the region endpoint) instead of the correct media-bucket.nyc3.cdn.digitaloceanspaces.com (the CDN endpoint). The engineer makes this mistake because they copied the bucket endpoint URL from a previous configuration step instead of the CDN-specific endpoint shown in the CDN custom-domain configuration dialog. The CNAME resolves; cdn.client.com points at the region endpoint. The region endpoint serves the bucket's content correctly (because it's the same backend storage) but presents the cert for *.digitaloceanspaces.com — not cdn.client.com. Browsers receive content with cert-mismatch warnings. The agency engineer sees content arriving correctly when testing via curl with --insecure flag and assumes the setup is correct. The cert mismatch only surfaces when a customer reports the browser warning. The fix requires updating the CNAME to point at the CDN endpoint (not the region endpoint) and waiting for DNS propagation; the silent-failure window was hours.
How it works
SSL and DNS monitoring for DigitalOcean agencies across App Platform managed-cert CNAME validation, Droplet Certbot renewal cron jobs, and Spaces CDN custom-domain endpoint configuration.
Merlonix monitors SSL expiry and DNS integrity across every DigitalOcean-attached subdomain — app.* (App Platform), api.* (Droplet with Certbot), cdn.* (Spaces CDN) — and catches App Platform managed cert provisioning failures caused by CNAMEs pointing at the wrong target after a Droplet-to-App-Platform migration, Droplet Certbot renewals that have stopped silently after a resize broke the cron daemon, and Spaces CDN custom domains where the CNAME points at the region endpoint instead of the CDN endpoint — before clients see browser warnings.
01
Add DigitalOcean application domains — apex, www.*, app.*, api.*, cdn.* — with DNS TXT verification that catches App Platform CNAME mistargeting and Spaces CDN region-vs-CDN endpoint confusion
Verify ownership with a DNS TXT record on the apex domain. All subdomains under that apex — app.* (App Platform), api.* (Droplet with Certbot), cdn.* (Spaces CDN) — are added without additional verification. Monitoring every DigitalOcean-attached subdomain catches the App Platform CNAME mistargeting (the served cert won't match the configured hostname when the CNAME points at the wrong target) and the Spaces CDN region-vs-CDN endpoint confusion (the cert presented for cdn.client.com will be *.digitaloceanspaces.com if the CNAME points at the region endpoint rather than the CDN endpoint). Under two minutes per client.
02
CNAME monitoring across registrar nameserver changes, App Platform deployment target updates, and Spaces region-vs-CDN endpoint distinctions — surfacing the wrong-target CNAMEs that break SSL silently
Three independent DNS resolvers check every CNAME delegation on every monitoring interval. App Platform deployment target updates (when a new app is deployed and the old <app>.ondigitalocean.app target is decommissioned) are surfaced immediately if the client's CNAME still points at the previous target. Spaces CDN custom-domain CNAMEs pointing at the region endpoint instead of the CDN endpoint are surfaced as cert-host mismatches. The DigitalOcean dashboard shows healthy because health checks use the platform endpoint not the custom domain; Merlonix monitors the custom domain directly.
03
SSL monitoring 30 days before expiry across App Platform managed certs (auto-renew but CNAME-dependent), Droplet Certbot certs (manual renewal — the silent failure mode after a Droplet resize), and Spaces CDN custom-domain certs (separate from the bucket cert)
Full SSL chain validation on every DigitalOcean-attached subdomain — apex, app.*, api.*, cdn.*. Independent checks per-platform catch Droplet Certbot renewal failures within 30 days of cert expiry — not 90 days after the cron daemon stopped firing. App Platform managed certs that have silently failed to provision (because the CNAME points at the wrong target) are surfaced within the first check cycle because the served cert's CN/SAN won't match the configured hostname. Spaces CDN custom-domain certs are checked separately from the bucket cert, so a region-vs-CDN endpoint CNAME mistake is surfaced immediately. An expiry alert fires 30 days before any cert expires, with separate alerts per platform so the App Platform cert and the Droplet Certbot cert can't mask each other.
04
Vendor status for DigitalOcean (per-region status pages — NYC3, SFO3, AMS3), App Platform, Droplets, and Spaces to distinguish DigitalOcean regional incidents from per-tenant SSL configuration failures
Merlonix monitors DigitalOcean's per-region status pages, App Platform, Droplets, and Spaces alongside client SSL and DNS. When an NYC3 App Platform regional incident causes managed-cert provisioning failures across multiple client tenants simultaneously, you see the vendor event — not a cluster of individual SSL alerts that each require separate investigation to determine whether the root cause is a DigitalOcean regional outage, an App Platform CNAME mistargeting from a recent Droplet-to-App-Platform migration, or a Spaces CDN region-vs-CDN endpoint configuration mistake.
What the numbers mean for DigitalOcean agencies
Monitoring built for DigitalOcean agencies where one client product means an App Platform deployment at app.* (managed cert with CNAME-dependent provisioning), a Droplet at api.* (Certbot renewal cron job — manual responsibility), and a Spaces CDN endpoint at cdn.* (separate cert from the bucket, separate CNAME pointing at the CDN endpoint) — each with independent cert lifecycles and independent failure modes.
DigitalOcean agencies managing App Platform managed-cert provisioning across multi-deployment frontends, Droplet Certbot renewals across multi-Droplet portfolios, and Spaces CDN custom-domain endpoints across multi-bucket asset deployments need monitoring that covers every DigitalOcean-attached subdomain — because an App Platform managed cert provisioning failure is silent (the dashboard shows the deployment healthy because health checks use the platform endpoint), a Droplet Certbot renewal failure is silent (no platform alert ever fires), and a Spaces CDN region-vs-CDN endpoint CNAME mistake is silent (the bucket returns content correctly but with a wrong-host cert).
< 10 min
Time from DNS change to alert — catches App Platform CNAME mistargeting after Droplet-to-App-Platform migrations, registrar nameserver changes that strip Certbot validation records, and Spaces CDN custom-domain CNAMEs pointing at the region endpoint instead of the CDN endpoint
30 days
SSL expiry warning lead time — enough time to identify a Droplet Certbot renewal failure (the cron daemon stopped firing after a resize live-migration, no platform alert ever fired), an App Platform managed cert provisioning failure caused by CNAME mistargeting, or a Spaces CDN region-vs-CDN endpoint CNAME mistake — and correct it before clients see browser warnings
11 vendors
Upstream services monitored — DigitalOcean per-region status pages (NYC3, SFO3, AMS3), App Platform, Droplets, and Spaces included to distinguish DigitalOcean regional incidents from per-tenant SSL configuration failures
200 assets
Maximum monitored domains on the Agency plan — covers DigitalOcean app.* (App Platform), api.* (Droplet with Certbot), cdn.* (Spaces CDN), plus per-region Droplet endpoints across a full DigitalOcean client portfolio
Pricing
Flat monthly fee. Every DigitalOcean region, every Droplet, every Spaces CDN endpoint included.
No per-region charges. No per-Droplet fees. Pick the tier that fits your DigitalOcean client and per-platform cert count and monitor every App Platform, Droplet Certbot, and Spaces CDN SSL surface without billing surprises.
Starter
For individual DigitalOcean developers managing a small client portfolio with single-region App Platform deployments and Droplet hosting.
$29/ month
- 10 monitored assets
- 1 seat
- 15-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For DigitalOcean agencies managing multi-Droplet and App Platform deployments with separate Certbot, App Platform managed certs, and Spaces CDN custom-domain certs.
$79/ month
- 50 monitored assets
- 5 seats
- 10-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies with a full DigitalOcean client roster including multi-region Droplets, multi-deployment App Platform, and per-tenant Spaces CDN custom-domain endpoints.
$199/ month
- 200 monitored assets
- 15 seats
- 5-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when a Droplet Certbot cron job has stopped firing after a resize before the cert expires 25 days later.
Add your first DigitalOcean client domain in under two minutes. App Platform, Droplet Certbot, and Spaces CDN SSL across every region for that client are monitored from the same dashboard. 14-day trial, no card required.