Netlify serve old cached version

CDN is
x-nf-request-id: 63b24c7c-90b8-4f4b-a41f-bff7448b006a-62026476

date is July 14th 7pm GMT :frowning:

What happened guys? I’m virtually offline since last Friday :frowning:

Surely there’s something someone could do? Why is it not replicating?

Hey @tcp,

Until the team working on this have more information, my hands are tied.

One workaround I could suggest is re-creating the site and ensuring that the content is correctly served before adjusting your DNS records (or, for Netlify DNS, asking us to move them over bumplessly) to point to the new site.

1 Like

OK. Thanks for checking. That was my concern. Cool.

Well, this is not same hugo case. My hugo setup is clean and verified since a long time.

So I guess this is some client dealing badly with cache or saved pages.
So at the moment I’ll consider it as solved, and will keep on looking.

Anyway thanks for validating that all node serve the same version. That was the main concern.

1 Like


We had to dive pretty deep in to this one! We’ve performed some pretty heavy cache changes for you to remediate the problem. Sorry for not following up sooner; we fixed the issue much sooner than this (11 days ago) but we continued to investigate until yesterday.

Hey @Pie!

Unfortunately, it’s still the case for us. Just happened now, with multiple users.

Hey @tcp,

I ran tests earlier today and was able to identify that our CDN PoPs were all serving the same deploy. Is this perhaps client-side? Happy to test again if you can’t resolve!

Hey @Pie!

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 @Pie

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.