From my reading on cache timeouts, I had the impression that they could be set by s-maxage=31536001 in the header.
And that a page rule that applies with Edge Cache TTL:a month would override that. That, even if the header shows s-maxage=31536001, Cloudflare will actually be using the rule setting.
Last evening, 17 pages showed cf-cache-status:HIT.
The next morning, 4 pages showed MISS, and 13 pages EXPIRED.
Running my script a 2nd time, now they are all HITs, so that’s working okay.
It appears that one-of Bluehost, WP Super Cache, or Cloudflare is expiring only some of that cache. As it took overnight, this may take some time to ring out.
My question here: Is my understanding of Cloudflare caching correct?
Do you have Cache-control HTTP header setup on your origin?
Moreover, are you using “Respect existing headers” option for Browser Cache TTL in Cloudflare dashboard or some other option available from the dropdown select? Because, it can overwrite your settings, or setup the correct one as choosen.
Could be due to other Cache-control, ETag, Pragma, etc. headers.
Moreover, if using Last-modified, and if some of it are having different values depending if you have updated some content and the WP Super cache re-generated the .html, and the Cloudflare edge does not have “the new one”, it could be that difference as I suppose.
It appears this may happen with Wordpress when using a caching plugin that recognizes Cloudflare, but NOT including the Wordpress Cloudflare plugin. Everything will seem fine, with no log errors, but some cache loads will be slower and expirations may happen overnight.