How to run the 25 Cloudflare health checks for a Magento store

Most Cloudflare-in-front-of-Magento problems are one setting, and none of them show up in a Magento log. OCM Labs Cloudflare, the free and open source module, ships 25 health checks that read the zone, the Magento config and the live storefront and tell you what to change.

Where the checks live

1. Open System > Cloudflare > Dashboard, pick the website and click the Health tab. Every check is listed with a status of pass, warn, fail or skip, a one-line fix and the evidence the check used.
2. The checks run hourly from cron, at 15 minutes past the hour. Click Run checks now to run them on demand.
3. Where a fix is a single zone setting, an Apply this fix button changes it from the admin. The button needs the OCMLabs_Cloudflare::settings_write ACL resource, so a role without it sees the result but not the button.

The same checks run from the command line:

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

Without --website the command runs for every website that has a zone configured. The plain form prints a table of status, check and message; --json prints the full results with status, message, fix and evidence per check. It exits 1 when any check fails, 2 on bad input, 0 otherwise. The full list is on the health checks docs page.

Connection (2 checks)

If either fails, fix it first; everything below depends on it.

Zone settings (7 checks)

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

Cache rules (5 checks)

The fix for most of this group is the same: apply the recommended rules, from the Health tab or with bin/magento ocmlabs:cloudflare:rules:apply. Post 4 covers the six rules, the diff and writing them by hand.

Magento (6 checks)

Real visitor IP inspects the admin request you just made. From bin/magento there is no Cloudflare request to inspect, so it reports skip. Click Run checks now from an admin session that came through Cloudflare to get an answer.

Live probes (5 checks)

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.

The origin probe only runs when Storefront Origin is set, so a skip on that row means the field is blank. TLS certificate verification is skipped for that fetch, because origin certificates are rarely valid for the public host. 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:

• Message: what was found.
• Fix: what to change, and where in the Cloudflare dashboard.
• 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. To see by hand what the origin probe sees:

curl -sI -H "Host: www.example.com" https://<origin ip>/some-category.html -k | grep -iE "cache-control|cache-tag"

You should get Cache-Control: public, max-age=0, s-maxage=... and a Cache-Tag line.

Using the command as a deploy gate

Because the command exits 1 on any failed check, it slots in as the last step of a deploy, after the rules are applied and the cache is purged:

#!/usr/bin/env bash
set -euo pipefail

bin/magento ocmlabs:cloudflare:rules:apply
bin/magento ocmlabs:cloudflare:purge --all

if ! bin/magento ocmlabs:cloudflare:health --website=base --json > var/log/cloudflare-health.json; then
  echo "Cloudflare health checks failed:" >&2
  cat var/log/cloudflare-health.json >&2
  exit 1
fi

Two limits. Warns do not fail the command, so a stopped purge consumer will not block a deploy; only fails do. And Real visitor IP is always skip from the CLI, so the gate cannot catch a wrong CF-Connecting-IP setup. The same JSON feeds a monitor: run it on a schedule and alert on any fail.

Which checks to look at first

For the DYNAMIC case, the settings that make a page cacheable are in post 2. One cause no check finds: a block with cacheable="false" in the layout makes the whole page uncacheable. Search the theme and extensions for it.

If you want someone to run the checks against your stack and fix what fails, our performance and infrastructure team does this for Magento stores behind Cloudflare.