Edge Cache TTL

Hello again,

I want to know what the default value of Edge Cache TTL is?

Also, please let me know how I may know programmatically when my file at Edge Cache is going to expire?

Thanks & Regards,


Cloudflare offers a range of edge cache TTLs by plan type:

Free 2 hours
Pro 1 hour
Business 30 minutes
Enterprise as low as 30 seconds

Also check this out Edge Cache TTL & here


I know this TTL value can be set via Page Rule.

I am asking without setup of Page Rule, how much TTL Cloudflare set for edge Cache?
Does Cloudflare keep same TTL Value as max-age?

Most important, I would like to assure myself by checking it personally, if there is any way please let me know.


1 Like

This question was asked around two years ago on a Cloudflare blog and the response was

“There is no maximum really, but our edge caches are subject to being cleared when we have to do work on the colo, to add more servers for example.”;

Cloudflare will cache static content by default. We will default to the following TTL depending on the return code: 200 301 120m; 302 303 20m; 403 1m; 404 5m; any 0s;

Sending cache directives from your origin for resources with extensions we don’t cache by default will make absolutely no difference. To specify the caching duration for the extensions we don’t cache by default, you’d have to set Edge Cache TTL and create a Page Rule to “Cache Everything”./

I’m sure you could use ‘curl -I https://example.com/image.png’ or google chrome dev tools would show you when the file is going to expire.

Please let me know if you need any help.

1 Like

Cloudflare will respect your origin expires / cache control headers to calculate the Edge Cache TTL (providing you don’t override it with a page rule setting an explicit Edge Cache TTL).

Note that as with any cache your item may be evicted if the item is not requested frequently.

You can check whether an item is still in the cache by checking the headers:


If you see a HIT then it’s still in the cache.


Thanks for clarifying.

Still doesn’t answer the question… if i set a page rule to keep cache on the edge server for 30 days why am i seeing misses on all of my cached items after only a day or so… When does my cache get forcefully evicted? As in how often does it need to be accessed to stay in cache? Seems like if i set a page rule for 30 days it should stay there for 30 days no matter how much its accessed… One JS file that needs to be repulled can slow a site down.


Cache is maintained on a per POP basis, so each POP is going to maintain its own cache. It is possible a certain item could be frequently accessed in certain POPs and not others. It’s also possible that a piece of content may not be requested for a particular piece of content ever (or could be requested from POP A today and POP B 3 weeks from now).


Im monitoring what pop is serving my content in the headers and i am hitting the same pop yet my content is not remaining on the edge servers, I set a rule to set all ttl to 1 month on edge servers, doesnt seem to respect this rule.

1 Like

Then it would likely be that as Simon mentioned the content is being accessed infrequently enough that it was evicted from the cache and we’d then retrieve store it with the same maximum TTL specified when it was next requested for a user from that POP.

1 Like

So to be clear the rules are not an end all, they are a suggestion. CF servers still have their own idea of what should be cached and do not strictly abide by those rules… So using them is a waste of my rule allotment.


That’s up to you. I use Cache Everything frequently and it generally helps on sites with regular traffic. On one of my local org sites, it’s quite effective. It’s a local audience using the same POP, and I know the page is staying in the Edge Cache (fixed typos don’t go away until we purge the cache).

Even within a POP, I’m not entirely sure every server in that POP will have that resource cached. But if the site is accessed regularly by enough people, Edge Cache is very effective.

1 Like

You can apply a edge_cache_ttl value in your zone override settings when you update your zone configuration using the API (or Terraform).


I’m guessing this will set the value for your zone so that you don’t have to rely on the self-regulation described here.