> If you're fancy you can even programmatically purge the cache when you do CI deploys using the cloudflare API.
You need to be really careful with this.
I'm not sure how you've got things set up but isn't this going to lead to issues unless you have a cache busting or revalidation strategy? You can purge Cloudflare's cache but that's not going to purge the cache on browsers that already visited your site and cached a page already. You might get cases where an old cached HTML page is asking for page resources that don't exist anymore or pages break because the user is seeing the old HTML with the new CSS/JavaScript.
Also, if you can log in to your site, it can potentially cache one user's logged in page content and share it with others if your Cache-Control settings don't include "private".
You could set things up to make sure the browser and then the Cloudflare cache always asks your server first if a page has been updated recently (revalidation) but your server has to be configured right for this (e.g. etag or modified date usage).
Cloudflare is actually meant to have a feature that keeps a static version of your site to show in the event of outages:
Ref: https://support.cloudflare.com/hc/en-us/articles/202238800-W...
Where it doesn't help is if Cloudflare itself is having issues (all it does is move the weak link one layer up in this case). But that is easy enough to disable (assuming the cloudflare API or dashboard is up).
However, I do agree that it should be possible to turn on without pagerules for these sorts of scenarios.
However, the case of a static website is not really hitting me as something can't afford a few seconds downtime...
EDIT: Oops. Misread cloudflare/CloudFront.
Thanks for replying, but unless you're willing to explain to the rest of us why so, why bother? I can't make heads or tails of this pissing contest thread.
"Site Delivery" is purged globally within 7 minutes.
"Fast purge" enabled products (site delivery) is purged globally in under 20 seconds.
All assets for websites are site delivery. Only media services family of products are not site delivery. Those purge within a couple of hours. If you are someone who uses media services products, you know how to force Akamai to go back to origin globally instantaneously and how to trigger invalidation. In media services you should never serve stale.
For inner pages, browsers do consider /your-page-url?v=1505418887 to be a completely different page from /your-page-url?v=1505418888.
However, just expiring cache and/or properly setting HTTP cache control headers at most CDN's is a cleaner and more correct option.
I was just pointing out that some people adjust their menu links (etc) to include some sort of dynamic variable (ie /?ts=xxx). I don't recommend this sort of scheme, though, except in unusual circumstances: IMO, it's fragile, leaky, and inefficient.
https://support.cloudflare.com/hc/en-us/articles/200172256-H...
This downtime made me realize we weren't caching any html on cloudflare. I just turned it on and all our static sites are doing fine now (and our bills are smaller!).
If you're fancy you can even programmatically purge the cache when you do CI deploys using the cloudflare API.