How to use Cloudflare development mode and analytics from the Magento admin

Most day-to-day Cloudflare work on a Magento store is small: switch development mode on before a theme deploy, purge a few URLs after a content change, check whether the cache hit ratio moved after a rule change. With OCM Labs Cloudflare, a free and open source Magento module, none of it needs a second tab logged into Cloudflare. This post walks the Overview and Analytics tabs at System > Cloudflare > Dashboard, plus the matching CLI commands.

It assumes the module is installed, the token is in place and the website is connected to a zone. If not, start with how to set up Cloudflare for Magento.

What the Overview tab shows

Open System > Cloudflare > Dashboard. It lands on the Overview tab for the selected website, and the top of the tab is a status block:

• Connection status.
• Zone name and plan.
• Whether development mode is on.
• The edge cache settings in force: enabled or not, and the edge TTL.

Below that sit three panels: development mode, quick purge and a Health summary. Opening the dashboard needs the OCMLabs_Cloudflare::dashboard ACL resource; the buttons on it are gated separately, so a role can look but not touch.

Step 1: turn on development mode before a theme deploy

Development mode stops Cloudflare caching for the zone for 3 hours. Use it when you are about to deploy CSS, JavaScript or template changes and want every request to reach the origin while you check the result, without purging over and over.

1. On the Overview tab, find the Development mode panel.
2. Turn it on. The status block updates to show development mode is on.
3. Deploy the theme and check the storefront. Every request now goes to the origin.
4. When you are done, turn it off. A checkbox on the way off offers to purge everything, so visitors do not get a page Cloudflare cached before the change. Tick it unless you have a reason to keep the old cache.

Cloudflare turns development mode off by itself after 3 hours, so a forgotten switch does not leave the zone uncached all weekend. A deploy window longer than that needs the switch flipped again.

The switch needs the OCMLabs_Cloudflare::settings_write ACL resource, and the API token needs Zone:Settings:Edit.

The same from the CLI

In a deploy script, use the command instead of the button:

bin/magento ocmlabs:cloudflare:dev-mode on --website=base
# deploy the theme
bin/magento ocmlabs:cloudflare:dev-mode off --website=base

--website is repeatable; leave it off and the command runs for every website with a zone configured. The CLI command only flips the switch, so follow the off with a purge for the same effect:

bin/magento ocmlabs:cloudflare:purge --all --website=base

Step 2: quick purge from the Overview tab

The Quick purge panel takes cache tags, URLs or prefixes, one per line, or purges everything for the selected website. Prefixes are host plus path, for example www.example.com/catalog.

Quick purges skip the queue and run immediately, so the result shows straight away. They still land in System > Cloudflare > Purge Log with the mode, item count, status and Cloudflare's request ID. The panel needs the OCMLabs_Cloudflare::purge ACL resource.

For how the queued purges work, the purge modes and the rate limits per plan, see how to purge Cloudflare cache from Magento.

Step 3: read the Health summary

The Health panel summarizes the last health run: pass, warn, fail and skip counts, and when it ran. It links to the Health tab for the full 25 checks with their evidence and fixes. Checks run hourly from cron, so a stale timestamp usually means cron is not running.

Step 4: check the same figures from the CLI

Everything in the Overview status block is available from the command line:

bin/magento ocmlabs:cloudflare:status

It prints, per website, the zone name and ID, the plan, development mode, whether edge caching is on and the edge TTL. Exit code 1 means a Cloudflare call failed or no listed website has a zone, so it doubles as a smoke test at the end of a deploy.

Step 5: read the Analytics tab

The Analytics tab reads Cloudflare's GraphQL Analytics API for the website's zone. Each panel loads on its own, so a failed query in one panel shows an error there and the rest of the tab still loads.

After an edge caching change, watch Cached requests / hit ratio and Top paths. A low hit ratio with checkout and account URLs at the top of the paths list is a bypass path doing its job, not a bug.

The Range selector

Cloudflare keeps analytics for longer on higher plans, so the Range selector only offers what the zone can answer:

The 24 hour range uses minute-level data; the 7 and 30 day ranges use daily data. Nothing in the module gates this; it is Cloudflare's retention per plan.

Step 6: tune the analytics cache and the warm-up cron

Analytics responses are cached in the ocmlabs_cloudflare cache type, so opening the dashboard several times in a row does not hit Cloudflare's API each time. Two settings control this, both at Stores > Configuration > OCMLabs > Cloudflare > Analytics, default scope:

A cron job runs every 15 minutes and warms the cache for each website's default range, which is why the tab usually opens with data already there. The 900 second default matches that interval. Raise the TTL and the tab shows older numbers; lower it and more dashboard opens become API calls.

Set Enable Analytics to No to hide the tab and stop the warm-up cron from fetching. The config paths for scripts:

bin/magento config:set ocmlabs_cloudflare/analytics/analytics_enabled 1
bin/magento config:set ocmlabs_cloudflare/analytics/analytics_cache_ttl 900

Step 7: fix an empty Analytics tab

If the tab is empty or shows an error, check these in order:

1. The API token has Analytics:Read. Without it the tab reports the permission error Cloudflare returned.
2. Enable Analytics is Yes.
3. One panel errors while the rest load. Cloudflare changed a GraphQL field; the panel names the error and the other panels are unaffected. Report it.

With Debug Logging on, every API call is written to var/log/ocmlabs_cloudflare.log with the token redacted, which is the quickest way to see the exact error.

Where the charts come from

The charts are drawn with a vendored copy of Chart.js 4.4.1 that ships with the module. Nothing is loaded from a CDN, and the admin makes requests to your own Magento and Cloudflare's API and nobody else. That matters if your admin sits behind a content security policy or a network that blocks third-party hosts.

The full reference for both tabs is on the Dashboard & Analytics docs page.

If you would rather have someone set up Cloudflare in front of your Magento store and read the numbers with you, that is our performance and infrastructure work.