Netlify serve old cached version

Hey @Scott!

We had 2 websites deployed that used the same codebase. I guess only one of them was corrected – the other one was still facing difficulties earlier this week :frowning:

Thank you for the help though!

Hey! If you’ve got a URL, I can take a look.

Hi @Scott

I’ve been having the same issue for some time now. Clearing the browser cache helps. But after a second (regular) refresh it’s back to the old version. Have tried clearing cache and redeploy, but without any luck. The site URL is:

My netlify.toml looks like:

 for = “/*”
  Access-Control-Allow-Origin = “*”

Also noticed that my default subdomain just crashes (just displays a white page), if i don’t do a hard refresh.

Would very much appreciate the help. Thank you!

Hi, @oscar.carlstrom, I’m seeing that custom header returned when I test this site:

$ curl -svo /dev/null  2>&1 | egrep '< '
< HTTP/2 200
< access-control-allow-origin: *
< cache-control: public, max-age=0, must-revalidate
< content-type: text/html; charset=UTF-8
< date: Mon, 31 Aug 2020 04:24:44 GMT
< etag: "e471e38e38e2f67a2ddbd13daa161add-ssl"
< strict-transport-security: max-age=31536000
< age: 0
< server: Netlify
< x-nf-request-id: d16706a5-b176-4f72-aec7-e6b0b9eac131-8719323

I also checked the version of the site which was active when this post was made:

$ curl -svo /dev/null  2>&1 | egrep '< '
< HTTP/2 200
< access-control-allow-origin: *
< cache-control: public, max-age=0, must-revalidate
< content-type: text/html; charset=UTF-8
< date: Mon, 31 Aug 2020 04:25:42 GMT
< etag: "adf69840c74cbf1e8e220c18c58a8d4f-ssl"
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< x-robots-tag: noindex
< age: 0
< server: Netlify
< x-nf-request-id: 63bb63b2-a5bd-452b-acbe-14d6d2ba54fb-18562360

That also shows the header being sent.

Are you still seeing this issue? If so, would you please send us the x-nf-request-id header for the response without the access-control-allow-origin header?

Regarding the site displaying just a white page, that I wasn’t able to reproduce. Would you please share instructions about how to trigger that behavior?

If there are other questions for us, please include those at any time.

Thank you very much @luke! No, not at the moment. But it seems to appear on every other deploy. Only to somehow be fixed after a while. Not sure if that is after a fresh deploy (changed files) or after some time has passed. Do you have any thoughts on that?

Hi, @oscar.carlstrom, I don’t have any thoughts about it because I haven’t been able to see the issue happening.

If you send us the x-nf-request-id header for a response missing the header I can research it further. Without being able to see the issue happening, I’d only be guessing.

There more information about the x-nf-request-id header here:

If that header isn’t available for any reason, please send the information it replaces (or as many of these details as possible). Those details are:

  • the complete URL requested
  • the IP address for the system making the request
  • the IP address for the CDN node that responded
  • the day of the request
  • the time of the request
  • the timezone the time is in

To summarize, I’m happy to troubleshoot but in order to do this I’ll need this data (the x-nf-request-id header or the information it replaces) to direct that troubleshooting.

Hi again @luke. Ran in to this issue once more on the last delpoy. An old version of the site is being served.

This is the x-nf-request-id: ea969fa8-5524-4054-b9f4-039d53efbb7f-3374883

Anything else you need, just let me know.


Hi, @oscar.carlstrom. I checked the x-nf-request-id above. We didn’t serve that response today. The x-nf-request-id of " ea969fa8-5524-4054-b9f4-039d53efbb7f-3374883" was served on 2020-08-20 at 09:20:12 UTC, which is eleven days ago.

We did serve the site version which was deploy id 5f3e3fde5701ba000882e7a5 at that time. However, that was the currently published deploy at that time as the deploy with that id above was completed at 09:19:00 UTC (about a minute before the web request).

I’m not sure why the x-nf-request-id above is eleven days old. Do you have a service worker installed locally?

I don’t see one now but there could have been one before and your local browser is therefore caching page loads. That is the only reason I can think of that you would get such an old request id.

Thank you very much @luke! That explains it, yes I have. I tried out gatsby-plugin-offline a while back. And then removed it. I almost forgot about that.

Unregistered the service worker now, so it should help.

Thanks again!

1 Like

I get the exactly same issue. I can’t get the newest version on my chrome browser, even with hard-refresh, clearing cache locally, clearing cache on netlify, clearing cookies, etc. We don’t use a service worker and we haven’t specified custom caching headers.

However it works in other browser and in incognito. I have deployed multiple times with and without clearing cache and with new versions (changes in git), but I’m continually being served the old version.

I have even added some meta tags to the header with the COMMIT_REF value so I can see which version is served, but they never appear even appear (they do in incognito, so it should work).

Here is an request id for a request that does not work: x-nf-request-id: 4ce39d6e-364c-4c1a-b180-aeca1ebb22fc-21938284
Here is an request id for a request that works: x-nf-request-id: 4ce39d6e-364c-4c1a-b180-aeca1ebb22fc-21922364.

Hi, @nord. I’ve redacted your site’s subdomain (like in the information below. Please replace example with the actual subdomain for your site to use any URLs below.

Long story short, you have split tests enabled for this site here:

The request for the x-nf-request-id ending 84 was at 2020-11-10 14:13:13 UTC for this deploy:

That deploy id is the current deploy for the non-production branch in the split test (then and now).

The request for the x-nf-request-id ending 64 the deploy was at 2020-11-10 14:12:55 UTC returned the deploy below:

That is current deploy for the production branch (then and now).

To summarize, both requests do appear correct. There are two different versions being served depending on the nf_ab cookie value sent. If no cookie is sent, because the split test is 50:50, there is an equal chance for each version to be shown.

If there are other questions, please let us know.

Thank you so much! And how embarrassing that I forgot about our split test :sweat_smile: But it makes sense, and we have updated our split test branch now. Thanks again for the support :)!

1 Like

Hi there. I’m experiencing the same issue with an old version thats being served for my site

This is the old x-nf-request-id: 678a4629-8c2a-41aa-83ff-12dd8f645336-2330847.

If I empty my cache and refresh I get the new version with x-nf-request-id: b9aa59ee-c91e-4ad5-a892-be1b2c44c5e0-37983793

Any clue how I make sure the old version gets invalidated?

Thanks in advance!

[Update]: I seem to have another working x-nf-request-id: 513bad84-9b48-4f01-bd42-36577b5c746d-7568515, that I got after a couple of hard refreshes. If I do a soft refresh afterwards I always get the old one ending on 847 again.

Hi, @lmolema. This wasn’t a caching issue at Netlify. You have a local service worker installed and it is serving you the old version.

The following support guide has more information about how to find and remove the service worker:

How do I know it is a service worker? There are two reasons:

  1. The x-nf-request-id above (678a4629-8c2a-41aa-83ff-12dd8f645336-2330847) hasn’t been sent in the last 30 days. It is so old it is no longer in our logs at all.
  2. We only send a x-nf-request-id one time. They are unique ids and specific to a single request. The same x-nf-request-id will never get sent twice.

If you are getting the the same x-nf-request-id on subsequent requests, the only possible explanation is a service worker.

If there are other questions about this, please let us know.

Hi Netlify engineers,

I’m running into a similar issue. According to the headers the served javascript is a day old Fri, 29 Oct 2021 13:18:38 GMT, whereas I deployed a new build on 30 Oct 2021 at 21:53 GMT using the option “Clear Cache and Deploy Site”.

I don’t understand why the latest version is not being served.

It concerns x-nf-request-id: 01FK637J0SD4SEYJHKXA65G1X5

Would appreciate if you could have a look. Thanks!

Hi, @MickPerez. Our service will not cache content that far back and the date: header will still be the present date and time. The fact that you are seeing a date header from a month ago means it is nearly certain that response is coming from a local service worker:

Would you please read that support guide and let us know if removing the local service worker resolves the issue or not?

If it does not resolve it, would you please make a HAR recording of the issue occurring and share that with us?

Hi Luke,

Appreciate your fast answer. I had a closer look and it seems like changes to the linked github repo are not getting through to the Netlify.

I tried everything. Renaming the specific javascript file, push in git, pull into live, build & deploy the website. Switch off asset optimization. Reconnecting the Netlify instance to the github repo. Clearing the cache & rebuilding, etc. etc. I think I spent 150 Netlify minutes on rebuilding & redeploying the Jekyll site.
To no avail.

And suddenly I noticed a new button in the Deploy view which I previously not seen.
The button was called “Publish deploy”.
OMG, are you kidding me?!?! :roll_eyes:

So I clicked the button… and lo and behold all my changes have been published. :sweat_smile:
I think during my frenzied attempts I might have clicked on an option somewhere to stop automatically publishing deploys/builds.

Anyway Luke, thank you at least for offering suggestions.

I hope someday, somewhere this answer might prevent accelerated hair loss, pointless stress and wasted hours.


Hi, @MickPerez. We appreciate you taking the time to share the solution you found. It is a big help to others and will save somone from a “denvercoder9 scenario”. I do have a few more tips relating to deploys not updating the site.

You might also check to see if auto publishing is enabled or not. If you turn auto publishing on, then all new (successful) production branch deploys are automatically published.

Also, in a related thread, there is a “stop builds” setting (but that doesn’t seem to have been the issue here):

That doesn’t affect publishing. It affects if the build itself will occur on not for new commits to the repo.

Finally, there is one last edge case for new deploys now working. When manual deploys are made with the Netlify CLI tool they won’t auto-publish either - unless you include the --prod option to indicate the deploy is a production deploy:

netlify deploy --prod

Thanks again for your follow-up and new topics are welcome anytime.

I am writing here to say that reading this thread finally helped me with the same, what I thought, caching problem. I had enabled split testing a while back, but then later had turned off branch deploys. In the UI it turned split testing off, but it wasn’t really off. It was still sending 50% of my traffic to an old branch and the other 50% to the main branch.

So that seems to be a bug that needs to be fixed?

hi there @b00y0h - are you still seeing the problem? we had some issues with splitting, but those have since been resolved, so i would expect the situation to improve.