OCMLABS/MODULE-CLOUDFLARE · HEALTH CHECKS

The 25 health checks that tell you whether Cloudflare is set up correctly for your Magento store

Where to find them

System > Cloudflare > Dashboard > Health lists every check for the selected website with a status of pass, warn, fail or skip, a one-line fix and the evidence the check used. The checks run hourly from cron (at 15 minutes past the hour) and on demand with Run checks now. Where a fix is a single zone setting, an Apply this fix button changes it from the admin, which needs the OCMLabs_Cloudflare::settings_write ACL resource.

The same checks run from the command line, with --json for monitoring:

bin/magento ocmlabs:cloudflare:health
bin/magento ocmlabs:cloudflare:health --website=base --json

The command exits 1 when any check fails, so it can gate a deploy.

Connection

Check	What it looks for
API token	The token is valid and carries the permissions the module needs. Fix: create a new token with the permissions listed on the Installation page.
Zone matches storefront	The configured zone’s name matches the website’s storefront hosts. Catches a Zone ID pasted from the wrong zone.

Zone settings

These are Cloudflare settings that break Magento or make caching pointless. Each one shows the current value and offers an Apply this fix button.

Check	What it looks for
SSL mode	Full or Full (strict). Flexible makes Cloudflare talk HTTP to the origin, which loops with Magento’s secure base URL.
Rocket Loader	Off. It rewrites script loading and breaks RequireJS on Luma and Alpine.js on Hyva.
Auto Minify	Off on zones that still have it. Magento minifies its own assets, and Cloudflare’s minifier can break RequireJS modules and Alpine expressions.
Email Obfuscation	Off. It rewrites addresses inside rendered HTML and injects a script into cached pages.
Always Online	Off. It serves stale prices and stock from the Internet Archive when the origin is down.
Brotli, HTTP/2, HTTP/3 and Early Hints	On. Warns about each one that is off; none of them breaks Magento, they just make it faster.
Browser Cache TTL	Respect Existing Headers. Any override replaces the module’s `max-age=0` and keeps purged pages alive in visitors’ browsers.

Cache rules

Check	What it looks for
Storefront cache rule	A `[OCMLabs] Cache storefront HTML` rule exists for the website’s hosts.
Bypass rules	The bypass rules exist and sit below the cache rule, so they override it.
X-Magento-Vary handling	The vary cookie is handled, either by the bypass rule or by a custom cache key on an Enterprise zone. Fix: apply the recommended cache rules.
No POST caching	A rule bypasses non-GET requests.
Edge TTL	The TTL the cache rule applies matches the module’s edge TTL. Warns when a rule overrides the origin TTL.

Magento

Check	What it looks for
Cloudflare cache type	The `ocmlabs_cloudflare` cache type is enabled under System > Cache Management. The module stores zone details, analytics and health results in it.
Edge cache enabled	Enable Edge Caching of HTML is on for the website. Warns, rather than fails, because leaving it off is a valid choice.
Purge queue consumer	Compares the last cache clean event with the last completed purge. Warns when tags are queued but nothing has gone out, which usually means the consumer is not running.
Storefront theme	Detects Luma or Hyva for the website’s stores and notes which Cloudflare features would break it.
Multi-store edge caching	Lists the website’s store views and currencies and explains that visitors outside the default context bypass the edge unless Vary Handling is Cache key on an Enterprise zone.
Real visitor IP	Whether the current admin request’s `REMOTE_ADDR` was a Cloudflare address and `CF-Connecting-IP` was honoured. Only meaningful from an admin request that came through Cloudflare; skipped from the CLI. See Real Visitor IP.

Live probes

The probes fetch real storefront pages through Cloudflare and read cf-cache-status. They request a category page twice and expect the second to be a HIT, request a customer page and expect BYPASS or DYNAMIC, and send the vary cookie and expect the edge to step aside. Probe URLs come from the website’s own catalog, and a probe refuses to fetch anything that does not resolve to the configured storefront hosts.

Check	What it looks for
Edge caches a storefront page	A category page served through Cloudflare reports `cf-cache-status: HIT` on the second request.
Edge bypasses customer and checkout pages	The login page reports `BYPASS` or `DYNAMIC`, never `HIT`.
Edge handles the vary cookie	A request carrying `X-Magento-Vary` is not served from the edge cache.
Origin sends edge cache headers	Fetches the page directly from Storefront Origin, skipping Cloudflare, and checks that `Cache-Control` and `Cache-Tag` arrive intact. Fails when a proxy or Varnish between Magento and Cloudflare strips them. Skipped when Storefront Origin is blank. TLS certificate verification is skipped for this fetch, because origin certificates are rarely valid for the public host.
Cache-Tag header size	Samples storefront responses and reports pages whose tag list had to be truncated to fit Cloudflare’s header limits, with the paths involved. Those pages still purge on a full purge but may miss a tag purge.

Each probe needs the page to answer with HTTP 200; a redirect or error is reported as a failed probe with the status it got.

Reading a result

Every result carries three things: the message (what was found), the fix (what to change, and where in the Cloudflare dashboard) and the evidence (the raw values the check looked at, such as the setting value or the response headers). When you open a support issue, attach bin/magento ocmlabs:cloudflare:health --json, which includes all three for every check.