Cloudflare setup now checks your DNS records before installing a Worker
Automatic Cloudflare setup reads the DNS records for your hostnames and stops, with the fix spelled out, when a Worker on your zone would never see the site's traffic: a DNS-only record, or a host such as Lovable, Webflow or Framer that itself runs on Cloudflare.
A Cloudflare Worker only sees requests that pass through your own Cloudflare zone. Two common layouts mean they never do, and until now setup would install a Worker that sat there with zero invocations while the connection test waited.
- DNS only (grey cloud). The record sends requests straight to the origin. The review now names the record and asks you to switch it to Proxied, then check again.
- A host that itself runs on Cloudflare. Lovable, Webflow, Framer and similar platforms serve custom domains from their own Cloudflare account. With a proxied A record pointing at them, Cloudflare hands your requests to the host's zone and your zone's Workers never run. The review names the address, explains why, and asks for the host's CNAME proxy option instead, which is the layout that works.
The compatibility check needs one more token permission for this, Zone → DNS → Read. A token without it still gets the route and Custom Domain findings, and the review says plainly that DNS was not checked. Developer links carry the DNS findings too, and Logpush is not offered as a way round them, because a Logpush job for the zone would see no more of the traffic than the Worker would.
Also in this release: the ingest endpoint bound into an automatically installed Worker now follows your account's brand, so it matches the setup instructions you were shown.