Render's auto-SSL toggle can be silently disabled when an engineer adjusts routing rules.
The current cert keeps serving for 90 days. Then HTTPS breaks with no warning.
Render agencies running Web Services, Static Sites, and Cloudflare-in-front-of-Render deal with auto-SSL toggles that can be silently disabled in the Render Dashboard when an engineer adjusts routing rules (the previous cert continues to serve until its 90-day expiry then HTTPS breaks with no platform warning), Static Site to Web Service migrations where the cert does not carry over and the agency forgets to re-trigger auto-SSL on the new service, and Cloudflare-in-front cert provisioning loops where Render's HTTP validation is blocked by Cloudflare after a service rename or migration. Merlonix monitors every Render-attached subdomain so the silent auto-SSL disabling and cert-provisioning loops surface before clients see HTTPS breakage.
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 Render agencies get caught out
Three failure modes specific to Render deployments with auto-SSL toggle UI interactions, Static Site to Web Service migrations, and Cloudflare-in-front cert provisioning loops.
Render agencies deal with auto-SSL toggles that can be silently disabled via the Render Dashboard when an engineer adjusts routing rules, custom-header configurations, or redirect rules on the same custom-domain page (the previous cert continues to serve until 90-day expiry then HTTPS breaks with no platform warning), Static Site to Web Service migrations where the cert does not carry over and the agency forgets to re-trigger auto-SSL on the new service (the new service serves the platform default cert), and Cloudflare-in-front cert provisioning loops where Render's HTTP validation request is blocked or mangled by Cloudflare's edge after a service rename or migration (the existing cert expires and HTTPS breaks at both the Cloudflare and Render layers).
Render's auto-SSL toggle on a custom domain can be silently disabled via the Render Dashboard when an engineer adjusts routing rules, custom-header configurations, or redirect rules on the same custom-domain page. The previous cert continues to serve until its 90-day expiry — no platform alert fires when auto-SSL is disabled. The agency only discovers the broken HTTPS when the existing cert expires and the site starts serving an expired cert
A Render agency adjusts a redirect rule on a client Web Service's custom domain (e.g., redirecting old marketing URLs to new ones after a campaign rebrand). The Render Dashboard's custom-domain configuration page combines the auto-SSL toggle, the redirect rules, and the custom headers in one form. The engineer saves the form after editing the redirect rule. Render's form-submission logic interprets the unchanged auto-SSL toggle as "the user just set this value" and writes a state-change event. A subtle UI interaction (the form's default-state restoration on certain dashboard refresh patterns) flips the auto-SSL toggle off. The current cert (still valid for 60+ days) continues to serve. The engineer doesn't notice. 60 days later, the cert expires; auto-SSL is disabled so no renewal happens; the site serves an expired cert
A Render agency operates a client product on a Render Web Service with a custom domain at app.client.com and auto-SSL enabled. The auto-SSL cert was issued at launch (90 days ago) and has been auto-renewing on the 60-day mark every cycle. The client requests adding a set of redirect rules for an upcoming brand refresh: /old-product → /new-product, /old-pricing → /new-pricing. The agency engineer logs into the Render Dashboard, navigates to the Web Service, clicks the Custom Domain configuration. The configuration page shows: the custom domain (app.client.com), an "Enable automatic TLS" toggle (currently ON), a list of redirect rules (empty), and a list of custom HTTP headers (empty). The engineer adds the 4 redirect rules and saves. The save operation interacts with a UI form-state pattern that, under certain conditions involving the dashboard's state-restoration logic on refresh, can flip the auto-SSL toggle to OFF when the form is submitted. This is a known but rare UI-interaction bug that the Render team has acknowledged in their community forum but not fully patched. The engineer doesn't notice because the page redirects to the service overview after save, and the auto-SSL toggle isn't mentioned in any subsequent UI. The current cert continues to serve user traffic (it was issued 90 days ago, so still valid for ~30 days). 30 days pass. The cert expires. Render's auto-SSL would normally have renewed it 30 days before expiry — but auto-SSL is disabled now. The site serves an expired cert. Browsers throw cert errors. The agency engineer doesn't connect the redirect-rule change made 30 days ago to the cert expiry; tracing it back requires inspecting the Render Dashboard's audit log (which doesn't show toggle state changes) and noticing that the auto-SSL toggle is now OFF.
Render Static Sites and Web Services use different cert provisioning paths. Static Sites are served via Render's CDN with a different anycast IP target; Web Services are served via per-service backend infrastructure. When an agency migrates a client from a Static Site to a Web Service (common for adding dynamic content like a backend API or server-rendered routes), the cert does NOT carry over. The new Web Service starts without an auto-SSL cert; agencies often forget to re-trigger auto-SSL on the new service
A Render agency migrates a client marketing site from a Render Static Site to a Render Web Service to add backend API functionality. The migration plan: create the Web Service, deploy the new codebase, update the CNAME at the registrar to point at the Web Service's onrender.com URL, verify. The agency engineer completes the migration; the Web Service is deployed and the CNAME is updated. The engineer assumes the auto-SSL cert from the Static Site carries over to the Web Service because they share the same custom domain. But Static Site and Web Service certs are provisioned separately — the Web Service has no cert yet. The site serves an expired Static Site cert until auto-SSL fires (manually triggered) or until the cert is manually re-provisioned
A Render agency operates a client marketing site as a Render Static Site at app.client.com. The site uses HTML/CSS/JS only — no backend. The auto-SSL cert was issued at launch and has been auto-renewing every 60 days. The client launches a new feature requiring backend functionality: contact form submissions, lead-gen API, user accounts. The agency engineer decides to migrate from the Static Site to a Web Service to add the backend. The migration plan: create a new Web Service in Render, deploy the codebase with the new backend functionality, update the CNAME at the registrar to point at the Web Service's onrender.com URL, verify the deployment. The engineer creates the Web Service, adds the custom domain app.client.com to it, deploys the codebase. The Render Dashboard prompts the engineer to enable auto-SSL on the new Web Service — but the engineer assumes the cert from the Static Site carries over (because they share the same custom domain) and dismisses the prompt. The CNAME is updated. User traffic starts hitting the Web Service. The Web Service has no SSL cert — Render serves the platform default cert. Browsers throw cert-mismatch warnings. The engineer notices within minutes when the customer reports the warning; the fix is to enable auto-SSL on the Web Service, which takes ~10 minutes to provision. The downtime is short but the customer-visible incident is unforgiving for a marketing site migration that was supposed to be invisible.
Cloudflare-in-front-of-Render is a common pattern for adding WAF rules and caching. The CNAME points at Cloudflare; Cloudflare proxies to the Render service via the .onrender.com URL. Render auto-SSL works at launch because Render's HTTP validation request hits the Render service directly. But when the Render service is renamed or migrated to a new region, Render's auto-SSL flow tries to re-validate via HTTP — and Cloudflare blocks the validation request because the request now goes through Cloudflare's edge (which strips the validation token or routes it to the wrong origin). Render keeps retrying silently; the cert never re-provisions; the old cert expires and HTTPS breaks at both the Cloudflare layer and the Render layer
A Render agency puts Cloudflare in front of a client Render Web Service for WAF rules and DDoS protection. The CNAME for app.client.com points at Cloudflare; Cloudflare proxies to client-service-abc123.onrender.com. Render auto-SSL was enabled at launch and worked fine. A year later, the agency renames the Render service (client-service-abc123 → client-prod-v2-xyz789) to reflect a major version cut. The .onrender.com URL changes accordingly. The agency engineer updates the Cloudflare origin to point at the new .onrender.com URL. Render auto-SSL on the custom domain triggers re-validation — but the HTTP validation request now routes through Cloudflare (which has caching rules and a WAF), and Cloudflare blocks or mangles the validation request. Render keeps retrying silently. The existing cert is still valid for ~30 more days from cache; the customer-visible impact is delayed until the cert expires
A Render agency builds a client B2B SaaS on a Render Web Service at client-service-abc123.onrender.com with a custom domain app.client.com. Cloudflare is in front for WAF + bot mitigation; the CNAME for app.client.com points at Cloudflare; Cloudflare proxies to client-service-abc123.onrender.com via origin configuration. Render auto-SSL provisioned the cert at launch by performing HTTP validation against app.client.com — which hit the Render service directly before Cloudflare was added in front. The cert renewed cleanly every 60 days because the HTTP validation request kept resolving directly to Render. A year later, the agency renames the Render service (client-service-abc123 → client-prod-v2-xyz789) to reflect the v2 major release cut. The .onrender.com URL changes. The agency engineer updates the Cloudflare origin to point at the new URL. Cloudflare's WAF rules (configured 8 months ago) include a rule that blocks "suspicious" HTTP requests with unusual path patterns — and Render's HTTP validation request happens to match the pattern (it's a request to /.well-known/acme-challenge/<token> with an unusual user-agent). Cloudflare drops the validation request. Render auto-SSL retries every 6 hours; each retry is dropped by Cloudflare; the cert never re-provisions. The existing cert is still valid for ~30 more days from when it was last renewed. The agency engineer doesn't notice anything wrong because the site continues to work — until day 30 when the cert expires and HTTPS breaks at both the Cloudflare layer (which can't verify the origin cert anymore) and the Render layer (which can't provision a new cert because Cloudflare keeps blocking validation). The customer-visible incident takes hours to diagnose because the root cause involves three platforms (Render, Cloudflare, the registrar) and three different cert lifecycles.
How it works
SSL and DNS monitoring for Render agencies across auto-SSL toggle UI interactions, Static Site to Web Service cert handover, and Cloudflare-in-front cert provisioning loops.
Merlonix monitors SSL expiry and DNS integrity across every Render-attached subdomain — app.* (Web Service or Static Site), api.* (Web Service), plus any Cloudflare-fronted endpoints — and catches Render auto-SSL toggle silent disabling caused by routing-rule UI interactions, Static Site to Web Service migration cert gaps where the new service serves the platform default cert because auto-SSL was not re-enabled, and Cloudflare-in-front cert provisioning loops where Render's HTTP validation is blocked by Cloudflare's WAF after a service rename — before the existing cert expires and HTTPS breaks at both layers.
01
Add Render application domains — apex, www.*, app.*, api.* — with DNS TXT verification that catches Static Site to Web Service migration cert gaps and Cloudflare-in-front cert provisioning loops
Verify ownership with a DNS TXT record on the apex domain. All subdomains under that apex — app.* (Web Service or Static Site), api.* (Web Service), plus any Cloudflare-fronted endpoints — are added without additional verification. Monitoring every Render-attached subdomain catches the Static Site to Web Service migration cert gap (the new Web Service serves the platform default cert when auto-SSL is not re-enabled) and the auto-SSL toggle silent disabling (the served cert continues to serve from the previous provisioning until the 90-day expiry, then HTTPS breaks). Under two minutes per client.
02
CNAME monitoring across registrar nameserver changes, Render service renames, and Cloudflare origin configuration drift — surfacing the .onrender.com target rotations and Cloudflare-blocking-validation patterns
Three independent DNS resolvers check every CNAME delegation on every monitoring interval. When a Render service is renamed (the .onrender.com URL changes), Cloudflare-in-front configurations that point at the old URL are surfaced as drift events. The cert provisioning loop where Cloudflare blocks Render's HTTP validation request is detected because the served cert age starts to age past the normal 60-day renewal mark — Merlonix tracks the cert's notBefore date and alerts when it's older than expected for an auto-SSL-enabled service.
03
SSL monitoring 30 days before expiry across Render Web Service auto-SSL certs (auto-renew but toggle-dependent and Cloudflare-validation-dependent), Render Static Site certs (separate provisioning path from Web Services), and post-migration cert handover gaps
Full SSL chain validation on every Render-attached subdomain — apex, app.*, api.*. Independent checks per-service-type catch the auto-SSL toggle silent disabling (the served cert ages past 60 days without renewing, indicating auto-SSL is not firing), the Static Site to Web Service migration cert gap (the served cert switches from a Render-issued cert to the platform default cert), and the Cloudflare-in-front cert provisioning loop (the served cert ages past 90 days without renewing because Cloudflare keeps blocking validation). An expiry alert fires 30 days before any cert expires, with separate alerts per service so the Static Site cert and the Web Service cert can't mask each other.
04
Vendor status for Render (per-region status pages — Oregon, Virginia, Ohio, Frankfurt), Render Postgres, and Cloudflare to distinguish Render regional incidents from per-tenant SSL configuration failures
Merlonix monitors Render's per-region status pages, Render Postgres, and Cloudflare alongside client SSL and DNS. When an Oregon Render regional incident causes auto-SSL 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 Render regional outage, an auto-SSL toggle silent disabling from a recent dashboard change, or a Cloudflare-in-front cert provisioning loop caused by a Render service rename.
What the numbers mean for Render agencies
Monitoring built for Render agencies where one client portfolio means Web Services at app.* (auto-SSL but toggle-dependent), Static Sites at marketing.* (CDN-served with separate cert provisioning), and Cloudflare-in-front configurations at multiple subdomains (WAF + caching, but cert provisioning depends on Cloudflare not blocking validation) — each with independent cert lifecycles and independent failure modes.
Render agencies managing auto-SSL toggle UI interactions across multi-service portfolios, Static Site to Web Service migrations across multi-CMS frontends, and Cloudflare-in- front cert provisioning loops across multi-WAF setups need monitoring that covers every Render-attached subdomain — because the auto-SSL toggle silent disabling is silent (no Render Dashboard alert fires), the Static Site to Web Service migration cert gap is silent (the new service serves the platform default cert with no warning), and the Cloudflare-in-front cert provisioning loop is silent (Render keeps retrying but never succeeds; Cloudflare logs the blocked requests but agencies rarely review WAF logs).
< 10 min
Time from DNS change to alert — catches Render service renames that break Cloudflare-in-front cert provisioning, registrar nameserver changes that strip validation records, and Static Site to Web Service migration CNAME updates that arrive before auto-SSL is re-enabled on the new service
30 days
SSL expiry warning lead time — enough time to identify a Render auto-SSL toggle that was silently disabled during a redirect-rule change 30 days ago (the cert is about to expire and auto-SSL will not renew it), a Static Site to Web Service migration where the new service is serving the platform default cert because auto-SSL was not re-enabled, or a Cloudflare-in-front cert provisioning loop where Render keeps retrying validation but Cloudflare keeps blocking — and correct it before HTTPS breaks
11 vendors
Upstream services monitored — Render per-region status pages (Oregon, Virginia, Ohio, Frankfurt), Render Postgres, and Cloudflare included to distinguish Render regional incidents from per-tenant SSL configuration failures
200 assets
Maximum monitored domains on the Agency plan — covers Render app.* and api.* across both Web Services and Static Sites, plus Cloudflare-fronted endpoints across a full Render client portfolio
Pricing
Flat monthly fee. Every Render region, every Web Service, every Static Site included.
No per-region charges. No per-service fees. Pick the tier that fits your Render client and per-service-type cert count and monitor every Web Service, Static Site, and Cloudflare-in-front SSL surface without billing surprises.
Starter
For individual Render developers managing a small client portfolio with single-region Web Services and Static Sites.
$29/ month
- 10 monitored assets
- 1 seat
- 15-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For Render agencies managing multi-service portfolios with mixed Web Services, Static Sites, and Cloudflare-in-front configurations.
$79/ month
- 50 monitored assets
- 5 seats
- 10-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies with a full Render client roster including multi-region Web Services, multi-Static-Site CDN deployments, and per-tenant Cloudflare-in-front WAF configurations.
$199/ month
- 200 monitored assets
- 15 seats
- 5-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when Render's auto-SSL toggle has silently disabled before the cert expires and HTTPS breaks.
Add your first Render client domain in under two minutes. Web Services, Static Sites, and Cloudflare-in-front configurations across every region for that client are monitored from the same dashboard. 14-day trial, no card required.