Page Rule toggled by in audit log

Today, due to high traffic, I noticed that one of my page rules for caching disabled itself. Checking the audit log in my account, I noticed that the page rule was disabled by the user IP address “”, which I assume indicates that this was CF-internal.

I couldn’t find anything regarding this on here or in documentation, is this just something that can happen? Did any error on my side cause CF to turn the page rule off?


  "Old pr status": "active",
  "Pr behavior": {
    "Browser cache ttl": "2m0s",
    "Browser integrity check": false,
    "Cache level": "cache_everything",
    "Edge cache ttl": "2h0m0s",
    "Security level": "low"
  "Pr match": "*mydomain/*",
  "Pr priority": 1,
  "Pr status": "disabled",
  "Zone id": "[...]",
  "Zone name": "mydomain"

To note: I have no API keys on my account that are allowed to toggle page rules, and my account doesn’t seem to have been compromised.

I doubt, not really :thinking:

But, there is a Global API key out there, if being used by some plugin like caching plugins for WordPress, etc.

Thankfully, I hope.

May I ask if you are using eZoic ads maybe or Cloudflare Zero Trust/Teams, or Cloudflare WARP?

I don’t use WARP, any adtech or Zero Trust, and never logged into anything else like WP plugins with my CF account, sorry. It uses hardware-backed 2FA.

This makes me suspect of rules in general - I probably should not be relying on them for caching.

I found a “Caching change setting” action from in audit log, targeting a resource named “Zone always online” with the following metadata:

  "Name": "always_online",
  "Type": "caching",
  "Zone name": ""

However, the “Always Online” toggle was never turned on from its off (and known) position, and previously we never updated from the legacy Always Online to the new one.

Still trying to figure out if is indeed the Cloudflare network (is it?), why “Cloudflare” wasn’t the user performing this logged action.