Heroku ACM fails silently when your CNAME points at .herokuapp.com instead of .herokudns.com.
Heroku serves the platform default cert. Browsers reject it. The Heroku CLI says the cert is 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 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 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.
Heroku ACM (Automated Certificate Management) requires the CNAME to point at .herokudns.com (the DNS target — randomized per app, e.g., whispering-willow-5678.herokudns.com), NOT .herokuapp.com (the app endpoint). Agencies who migrated from a third-party cert to ACM often miss the CNAME change because both endpoints share the app name and look similar. ACM cert provisioning silently fails; Heroku serves the platform default *.herokuapp.com cert; browsers reject it. The heroku certs CLI shows OK because it reports on the ACM resource state, not the served cert
A Heroku agency migrates a long-running client app from a third-party cert (uploaded years ago via heroku certs:add) to ACM. The migration plan: enable ACM via heroku certs:auto:enable, update the CNAME at the registrar from <app>.herokuapp.com to <app>.herokudns.com, verify cert provisioning. The agency engineer enables ACM, updates the CNAME — but accidentally leaves the .herokuapp.com suffix in place. The CNAME at the registrar now points at <app>.herokuapp.com which is the app endpoint not the DNS target. ACM cert validation fails silently; Heroku serves the *.herokuapp.com platform cert. heroku certs reports the ACM resource as OK (the ACM resource exists), so the agency engineer marks the migration complete
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.
Heroku randomizes the .herokudns.com target during certain infrastructure events: region migration (e.g., US to EU), dyno tier change to a Private Space, app rename. The new DNS target is a different randomized hostname (e.g., murmuring-meadow-9876.herokudns.com). The agency's long-lived CNAME still points at the OLD target. ACM's cert validation for the custom domain succeeds against the OLD target (the cached cert is still valid); Heroku's NEW infrastructure for the app responds with the platform default cert when the user actually hits the app
A Heroku agency moves a client app from the standard US-region tier to a Private Space (enterprise dedicated runtime) for compliance. The Private Space migration assigns a new .herokudns.com target — different from the previous target. The agency engineer confirms the app is responding in the Private Space and considers the migration complete. The CNAME at the registrar is never updated. ACM continues to validate for the custom domain against the old target (cert is still valid); the new Private Space serves the platform default cert for actual user requests
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 Heroku SSL Endpoint apps (deprecated in 2017 but still active on grandfathered accounts) do NOT get ACM auto-renewal. The cert was uploaded via heroku certs:add years ago and renewal requires manually uploading a new cert via the same command. No platform alert exists. The agency only discovers the expiry when the cert expires and the site starts serving browser warnings. Older agencies with stable long-running clients still on SSL Endpoint are most exposed
A Heroku agency manages a client app that's been running since 2014 on Heroku with the legacy SSL Endpoint add-on. The cert was uploaded manually via heroku certs:add five years ago. The agency renews the cert every two years by uploading a new cert via heroku certs:update. The current cert was renewed three years ago — a 1-year cert that was reissued for 3 years via an extension. The agency engineer who set up the renewal cycle left the agency 18 months ago. The new owner of the client portfolio assumes ACM is handling renewal (because every other Heroku app at the agency uses ACM). The cert expires; the site starts serving browser warnings
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
200 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.
$29/ month
- 10 monitored assets
- 1 seat
- 15-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
- 50 monitored assets
- 5 seats
- 10-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
- 200 monitored assets
- 15 seats
- 5-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.