Heroku ACM fails silently on the wrong CNAME target.
It serves a default cert while the CLI says OK.
Heroku agencies running ACM (Automated Certificate Management), legacy SSL Endpoint apps, and Private Spaces deal with ACM cert provisioning that silently fails because the CNAME points at .herokuapp.com (the app endpoint) instead of .herokudns.com (the DNS target), randomized .herokudns.com target rotations during region migration or dyno tier changes (the cert keeps validating for the old target while new infrastructure serves the platform default cert), and legacy SSL Endpoint apps where ACM auto-renewal does not apply and certs expire silently because no platform alert exists. Merlonix monitors every Heroku-attached subdomain so the wrong-CNAME and expired-legacy-cert modes surface before clients see browser warnings.
No credit card either way — start free, or trial the full workspace.
- Check cadence (Agency)
- 1 min
- SSL pre-expiry alert
- 30 days
- Independent DNS resolvers
- 3
- Vendors watched
- 11
Where Heroku agencies get caught out
Three failure modes specific to Heroku deployments with ACM CNAME validation against .herokudns.com, randomized DNS target rotations during region or tier changes, and legacy SSL Endpoint apps without ACM auto-renewal.
Heroku agencies deal with ACM cert provisioning silently failing because the CNAME points at .herokuapp.com (the app endpoint) instead of .herokudns.com (the DNS target — these are different even though they share the app name), randomized .herokudns.com target rotations during region migration to a Private Space or a dyno tier change (the cert keeps validating for the old target while the new infrastructure serves the platform default), and legacy SSL Endpoint apps where ACM auto-renewal does not apply and the agency's renewal cycle depends on someone manually uploading a new cert via heroku certs:update before expiry.
ACM CNAME mistargeting
A CNAME left on .herokuapp.com instead of .herokudns.com fails ACM provisioning silently
A Heroku agency operates a client B2B SaaS that has been running on Heroku for four years. The original cert was a third-party cert uploaded via heroku certs:add a long time ago; the cert is approaching expiry and the agency wants to migrate to ACM for automatic renewal. The plan: heroku certs:auto:enable to enable ACM, update the CNAME at the registrar to point at the .herokudns.com target, remove the old cert via heroku certs:remove. The agency engineer runs heroku certs:auto:enable; the CLI confirms ACM is enabled. The engineer goes to the Heroku Dashboard, copies the DNS target value displayed under the custom domain configuration, and pastes it into the registrar's CNAME field. The DNS target value Heroku displays is <app>.herokudns.com — but the engineer's editor autocompleted .herokuapp.com from a recent copy of the app URL, and the engineer didn't notice the suffix difference. The CNAME at the registrar now points at <app>.herokuapp.com, which is the public app endpoint (the one users hit), not the DNS target (the one ACM expects). ACM's validation flow runs: queries the CNAME for the custom domain, gets <app>.herokuapp.com, attempts to validate the chain — but the chain doesn't resolve to an ACM-issued cert resource. ACM provisioning fails silently and retries every 6 hours. The app continues to serve the platform default *.herokuapp.com cert when requests come in for the custom domain. Browsers throw cert-mismatch warnings. The agency engineer runs heroku certs — output shows the ACM resource as "OK." The CLI is reporting the ACM resource state (the resource exists and is enabled), not the served cert state. Discovery happens only when a customer reports the browser warning; the silent-failure window was 6 hours.
herokudns.com target rotation
A Private Space or region migration rotates the .herokudns.com target while the registrar CNAME stays pinned
A Heroku agency manages a client product that requires SOC 2 compliance. The client moves to a Heroku Private Space (dedicated runtime, isolated network, encrypted-at-rest). The migration involves: provisioning the Private Space, creating a new Heroku app within the Space, copying the codebase and config vars over, switching traffic. The agency engineer completes all of these steps; the new app is reachable via the Private Space's endpoint. The new app's DNS target is a new randomized .herokudns.com value (let's call it murmuring-meadow-9876.herokudns.com). The previous app's DNS target was whispering-willow-5678.herokudns.com. The agency engineer assumes the CNAME from the previous app still works because the custom domain configuration was copied during migration — but the CNAME value at the registrar still points at whispering-willow-5678.herokudns.com. ACM's validation for the custom domain queries that CNAME; since the previous app still exists (the agency hasn't torn it down yet), the validation chain resolves to the old app's cert. ACM reports the cert as valid. But the new Private Space app serves the platform default cert when a user request hits it via the Private Space endpoint. The agency engineer cuts over user traffic — DNS at a different level points the custom domain at the Private Space endpoint. Browsers receive the platform default cert; cert-mismatch warnings begin. Discovery requires understanding that the .herokudns.com target is different from the app endpoint and that the agency's CNAME pinning is now stale.
Legacy SSL Endpoint expiry
Legacy SSL Endpoint apps get no ACM auto-renewal and no platform alert, so the cert expires silently
A Heroku agency was founded in 2012 and operates 30+ long-running client apps on Heroku. Half of the portfolio is on modern ACM; the other half is on the legacy SSL Endpoint add-on (apps created before ACM existed, where the original engineer uploaded a third-party cert via heroku certs:add and never migrated). The agency's lead Heroku engineer left the company 18 months ago and the SSL renewal cycle for the legacy SSL Endpoint apps was tribal knowledge — never documented. The current portfolio owner assumes ACM is handling renewal across the entire portfolio because the agency's SOP playbook (updated 3 years ago) says "Heroku handles SSL renewal automatically via ACM." This is true for the modern half of the portfolio but false for the legacy half. The legacy SSL Endpoint cert for one of the long-running clients expires. The site starts serving an expired cert. Browsers throw cert errors. The customer's end-users report broken HTTPS to the customer; the customer reports to the agency. The agency engineer runs heroku certs and sees the SSL Endpoint resource with an "Expired" status — but the same engineer ran the same command for an ACM-enabled app last week and the output looked similar. The engineer didn't notice that this app's heroku certs output was different (no "auto-renewal" indicator). Renewal requires obtaining a new cert from a CA (the legacy SSL Endpoint setup didn't use Let's Encrypt; the original cert was from a paid CA the agency no longer has an account with) and uploading it via heroku certs:update. Total downtime: 4 hours for the operational scramble; future audit reveals 7 other apps in the portfolio are also on the legacy SSL Endpoint pattern and could fail next.
How it works
SSL and DNS monitoring for Heroku agencies across ACM CNAME validation against the randomized .herokudns.com target, Private Space and dyno tier migrations that rotate the underlying DNS target, and legacy SSL Endpoint apps that require manual cert renewal.
Merlonix monitors SSL expiry and DNS integrity across every Heroku-attached subdomain — app.* and api.* (ACM-managed modern apps), plus any per-region or Private Space endpoints (where DNS targets rotate during migration) — and catches ACM cert provisioning failures caused by CNAMEs pointing at .herokuapp.com instead of .herokudns.com, randomized .herokudns.com target rotations during Private Space migrations breaking the agency's long-lived registrar CNAME, and legacy SSL Endpoint apps approaching expiry where no ACM auto-renewal is happening — before clients see browser warnings.
01
Add Heroku application domains — apex, www.*, app.*, api.* — with DNS TXT verification that catches ACM CNAME mistargeting (.herokuapp.com vs .herokudns.com) and randomized DNS target rotations during region or tier changes
Verify ownership with a DNS TXT record on the apex domain. All subdomains under that apex — app.* (ACM-managed), api.* (ACM-managed), plus any per-region or Private Space endpoints — are added without additional verification. Monitoring every Heroku-attached subdomain catches the ACM CNAME mistargeting (the served cert won't match the configured hostname because Heroku serves the platform *.herokuapp.com cert when the CNAME validation fails) and the randomized DNS target rotation (the agency's long-lived CNAME at the registrar still points at the old target while the new app infrastructure serves a different cert). Under two minutes per client.
02
CNAME monitoring across registrar nameserver changes, Heroku Private Space migrations, and dyno tier changes — surfacing the .herokudns.com target rotations that break ACM silently
Three independent DNS resolvers check every CNAME delegation on every monitoring interval. When a client app migrates from the standard US tier to a Private Space (or to a different region), the new .herokudns.com target is recorded — and the drift from the agency's long-lived CNAME at the registrar is surfaced immediately as an alert. The ACM resource may report OK for hours while the served cert is wrong; Merlonix monitors the served cert directly, not the Heroku CLI resource state, so the failure surfaces in the first check cycle rather than waiting for a customer complaint.
03
SSL monitoring 30 days before expiry across Heroku ACM-managed certs (auto-renew but CNAME-dependent) and legacy SSL Endpoint certs (manual renewal — the silent failure mode for grandfathered apps)
Full SSL chain validation on every Heroku-attached subdomain — apex, app.*, api.*. Independent checks per-cert-type catch ACM provisioning failures within the first check cycle (the served cert's CN/SAN won't match the configured hostname when ACM is silently failing) and legacy SSL Endpoint cert expiry 30 days before — not 4 hours into the outage when the customer reports the browser warning. Each legacy SSL Endpoint app gets the same 30-day pre-expiry alert as ACM apps, so the agency's renewal cycle is driven by Merlonix instead of by tribal knowledge that may have left with a departing engineer.
04
Vendor status for Heroku (US, EU, Private Spaces), Heroku Postgres, Heroku Redis, and Heroku Connect to distinguish Heroku regional incidents from per-tenant SSL configuration failures
Merlonix monitors Heroku's status pages alongside client SSL and DNS. When a Heroku US-region incident causes ACM 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 Heroku regional outage, an ACM CNAME mistargeting from a recent third-party-cert-to-ACM migration, or a legacy SSL Endpoint expiry that's been silently approaching for months.
What the numbers mean for Heroku agencies
Monitoring built for Heroku agencies where one client portfolio means modern ACM-managed apps at app.* and api.* (auto-renewal but CNAME-dependent), grandfathered SSL Endpoint apps that require manual heroku certs:update before each renewal cycle, and Private Space migrations that rotate the underlying .herokudns.com DNS target — each with independent cert lifecycles and independent failure modes.
Heroku agencies managing ACM-managed app portfolios alongside grandfathered SSL Endpoint apps that pre-date ACM, with some clients on standard dyno tiers and others on Private Spaces with rotating .herokudns.com targets, need monitoring that covers every Heroku-attached subdomain — because an ACM CNAME mistargeting failure is silent (the heroku certs CLI reports the ACM resource as OK even when the served cert is the platform default), a Private Space DNS target rotation is silent (the agency's long-lived registrar CNAME continues to validate against the old target), and a legacy SSL Endpoint expiry is silent (no ACM auto-renewal will fire).
< 10 min
Time from DNS change to alert — catches Heroku Private Space migrations that rotate the .herokudns.com target while the agency's registrar CNAME stays pinned to the old target, registrar nameserver changes that strip ACM validation records, and CNAME-mistargeting where an engineer copies .herokuapp.com instead of .herokudns.com
30 days
SSL expiry warning lead time — enough time to identify a legacy SSL Endpoint app approaching expiry (no ACM auto-renewal will fire; the agency's renewal cycle depends on a manual heroku certs:update before expiry), an ACM cert provisioning failure caused by CNAME mistargeting (the served cert is still the platform default), or a Private Space DNS target rotation breaking the agency's registrar CNAME — and correct it before clients see browser warnings
11 vendors
Upstream services monitored — Heroku status pages (US, EU, Private Spaces), Heroku Postgres, Heroku Redis, and Heroku Connect included to distinguish Heroku regional incidents from per-tenant SSL configuration failures
250 assets
Maximum monitored domains on the Agency plan — covers Heroku app.* and api.* across both ACM-managed modern apps and legacy SSL Endpoint grandfathered apps, plus per-region Private Space endpoints across a full Heroku client portfolio
Pricing
Flat monthly fee. Every Heroku region, every Private Space, every legacy SSL Endpoint cert included.
No per-region charges. No per-app fees. Pick the tier that fits your Heroku portfolio and per-cert-type count and monitor every ACM-managed and legacy SSL Endpoint cert without billing surprises.
Starter
For individual Heroku developers managing a small client portfolio with single-tier ACM-managed apps.
$19/ month
- 15 monitored assets
- 3 seats
- 5 min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For Heroku agencies managing mixed ACM and legacy SSL Endpoint portfolios, with separate cert lifecycles per app type.
$79/ month
- 60 monitored assets
- 10 seats
- 1 min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies with a full Heroku client roster including Private Space migrations with rotating .herokudns.com DNS targets, plus grandfathered SSL Endpoint apps that need manual renewal cycle management.
$199/ month
- 250 monitored assets
- Unlimited seats
- 1 min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Compliance
For regulated-vertical teams that need continuous, audit-ready evidence.
$699/ month
- 500 monitored assets
- Unlimited seats
- 1 min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when a legacy SSL Endpoint cert is approaching expiry — 30 days before, not 4 hours into the outage.
Add your first Heroku client domain in under two minutes. ACM-managed apps, legacy SSL Endpoint apps, and Private Space migrations across every region for that client are monitored from the same dashboard. 14-day trial, no card required.