Analytics shows 100% cache on dynamic pages

We are seeing 100% of the traffic showing as cached, yet our origin servers are still seeing all the requests and the dynamic content is still working as expected.
Its for about 300k requests per 24 hours which is about right but the cache stats just don’t marry up.
Do the stats only show for content that is cacheable, or is there a bigger reporting problem?

More likely is that uncached requests are not going through Cloudflare. Looking at your requests for the last 6 hours, the cached spike from 0 about 2 hours ago. Perhaps the machines you are testing with have a cached DNS value for www or whatever endpoint they are using for non-cached assets?

Hi, thanks for your response.
The requests were definitely going through the cloudflare CDN, we could see them hitting our servers from the cloudflare IP’s. The issue as it turns out was an app we installed from the cloudflare portal for logging. As soon as we disabled this app the analytics started showing a true representation of the requests etc. and looks as we’d expect. So with the app installed, the stats just showed everything as cached. I have more info if needs be for this.

Hmmmm… interesting. Assume that was logflare? @chasers

That is correct, they are aware and are looking into it from their side. However I’m guessing this is an issue within Cloudflare as surly if the content is being served correctly (whether from cache (as static files were) or requested from origin servers (as dynamic content was), the reporting should not be affected.


I am also experiencing this.

Logflare installed March 14.

Yep, I’m on it and can reproduce.

Posted this to Stack Overflow:

If there is no immediate obvious solution, I’m going to try pointing another domain outside of Cloudflare to the endpoint which takes all the logs and use that to send events from the app worker.

I’m thinking there is some recursion bug or something when an app worker makes a request to another domain on Cloudflare. Custom workers seem to work fine but I’ve noticed a couple other differences between custom workers and app workers.

1 Like

Ah … seems to be a known issue with Apps with workers:

“We have known bugs with analytics in the presence of Apps with Workers, which is why Apps with Workers is still in beta.”

I will see if I can get a timeframe from them.


@Judge @cscharff after doing some testing … I have two test sites where I simply enabled the basic default custom worker (no Logflare App worker) and analytics did the same thing. So I’m thinking if a worker is installed in your account no matter what it will have this affect on your CF analytics.

Can anyone confirm? Like just go add the default worker example (across the whole site), and this will happen. At least it did for me.

Appreciate it.

1 Like

in my case worker did not affect the analytics


Looks like it may have been fixed (only using the LogFlare app):

1 Like

It looks like the 100% party is over for me, too.


ugh… so back to work to cache the now non-100% (have to find them first)

@jonathand are you using Logflare and/or your own worker?

If you’re using Logflare you can easily see a better and more reliable cached percentage with DataStudio. You can also filter by metadata.response.headers.cf_cache_status. I made this for someone else:

If you’re not using Logflare you should use it for more reliable edge analytics :slight_smile:

DataStudio is also cool because you can set up this dashboard and get weekly emails with an overview of your cache status responses.


Here is exactly how to find the offending url with Logflare: