Receiving intermittent 400 errors

PLEASE help us help you by writing a good post!

    I am receiving intermittent 400 errors for static assets on my website. Responses sometimes load, and occasionally return a 400 like below.

I also have a HAR file for this if there is a way to upload.

Here is a response:

Request URL:
Request Method: GET
Status Code: 400
Remote Address: xx.xx.xx.xx:443
Referrer Policy: strict-origin-when-cross-origin
cache-control: no-store
content-language: en
content-length: 220
content-type: text/html
date: Sat, 07 Aug 2021 00:48:40 GMT
server: Netlify
x-nf-request-id: 01FCF1ANT467MPFS755C7XQPRZ
:method: GET
:path: /d8d30a814b3800fd65e4.png
:scheme: https
accept: image/avif,image/webp,image/apng,image/svg+xml,image/,/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
cache-control: no-cache
cookie: _ga=GA1.1.578417192.1627172554; _ga_2D64CQ3M8D=GS1.1.1628296661.40.1.1628297320.0
pragma: no-cache
sec-ch-ua: “Chromium”;v=“92”, " Not A;Brand";v=“99”, “Google Chrome”;v=“92”
sec-ch-ua-mobile: ?0
sec-fetch-dest: image
sec-fetch-mode: no-cors
sec-fetch-site: same-origin
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36


Hi there, @TeslaOwner :wave:

Welcome to the Netlify Forums! Thanks for reaching out.

You should be able to share the links to your HAR file in this thread!

Can you confirm when this issue began? Additionally, have you looked through the Forums for other related threads? This one may be of interest to you:

We’ve been seeing this issue as well. It’s extremely sporadic, so it’s essentially impossible to reproduce. It only happens for static assets like CSS and SVGs, it’s never happened during page load.

I don’t have a full request/response to share, but I can say the server returns HTTP 400. It also seems to happen for some of our users more often than others, but that could just be chance.

@hillary is there something we can try and collect to get to the bottom of this? Because it’s the Netlify servers returning a 400 it seems like it’s probably being recorded in a log somewhere…

1 Like

Could you share the site URL and probably the affected assets?

I submitted a ticket to support with a full .har file for the request. Here is one of the request IDs that failed if that helps track it down: 01FMQQHYVH5Y5JDDYN7P6SMY2Q.

I already went through this process with really pathetic results.

`Hey ,

I have to deliver some bad news today. Our team has several thoughts about how to address the situation, but the work planned cannot happen for several months. So, I can’t foresee a fix in the near future that will help you out.

I hate delivering news like this and I am certain it won’t please you, but the best I can do - since I can’t write the code to fix the problem, or even address the prerequisites - is to offer you that transparency so you can make the right choice for your business.

I can also offer you a refund of your last couple of bills and help migrating off our service, if you haven’t already.

Let me know what you think.`

Thanks for sharing, that’s concerning. Was this specific to the way you had your app configured? This can’t be happening for everyone…

Hi folks,

I’m the Director of Support at Netlify, and as such, I was working with @TeslaOwner, who took my response from our private helpdesk and quoted it here. Things can be easily taken out of context, which seems to be at risk of happening here, so I’d like to provide a little more information so everyone can make the decisions that they feel are in their best interests.

The behavior described has been extensively researched, but unfortunately, we have yet to discover a resolution to the problem that won’t cause other problems to the millions of other customers on our network. According to our research, this behavior affects something like <.001% of certain types of traffic, which leads to occasional HTTP 400 errors. ( I also need to explain for future explorers that this thread is only in regards to HTTP 400 errors. Other 4xx HTTP errors - 401, 403, 404 - are usually caused by other problems; please start a new thread to discuss). We are hoping that future work will affect this behavior positively, but I do not have a firm ETA if or when things may change.

The issue has been brought up and engineering team is aware of it - and of course, no team involved thinks this is ideal. Having errors in site service, however rarely, is not an experience we want you to have, and in an ideal world we would be able to fix this quickly and efficiently. At the moment, that’s not possible. I am choosing to be very transparent here, and I understand that that feels untenable for some.

If the decision you come to is that it is in your best interest to migrate off our service, we do understand and can help you with that. We can check in on each customer affected by this specific situation and see if we can get you a refund for some of your charges, (if you are paying for our service).

Putting myself in your shoes, it’s not a perfect situation, but it is the best I can do.

Do let us know if you have further concerns, feel your site is affected by this, or need a way to contact us for assistance migrating off our platform, and we’ll take care of you as best we can.

1 Like

Thanks for the detailed reply, but it would be great to know what triggers this bug so that we can try and avoid it.

My app is just a create-react-app that loads very basic JS/CSS and some (~10) SVGs. It seems strange that it would trigger some subtle bug regularly. Also this bug sometimes triggers for the actual page load itself, which presents the user with a generic 400 Bad Request error and nothing else.

Can we get an update here @fool ? It’s critical for us to understand what causes this to happen.

I don’t have a full request/response to share, but I can say the server returns HTTP 400. It also seems to happen for some of our users more often than others, but that could just be chance.

1 Like

Agreed that it seems to favor some users more than others, but it’s hard to say for sure.

Hey there folks,

Thanks so much for your patience here. Unfortunately, we do not have any updates to share at this time. This is still being investigated and discussed internally. I know this isn’t the news you were hoping for! We will follow up on this thread when we have any updates to share.

Can confirm that we are seeing issue as well. Our website is for our product documentation, and it is just serving static HTML files with JS and CSS. Sometimes I see CSS not loading with 400.

Thanks for your transparency, and hopefully you guys can provide a fix soon.

1 Like

We’ve been seeing this issue as well; Random and intermittent GET requests for static files (SVG, JS, etc.) returning a 400 status code. It was difficult, but I was able to catch this issue in the act a couple times with DevTools open. I can provide a HAR file privately if it would benefit the engineering team (@fool, @hillary). This issue seems to be happening frequently for us.

For anyone else using Angular’s lazy loaded modules and receiving a “ChunkLoadError: Loading chunk XXXX failed” error intermittently … this 400 status code turned out to be the root cause for us.

1 Like

Sorry to hear about the trouble! This sounds like a behaviour that we are seeing on a small percentage of requests across our service, like the ones shared above in this thread. Based on our internal stats, it is happening to less than .02% of traffic. That’s still not the level of service we intend our CDN to provide, and so rest assured that our development teams are working on a solution.

I don’t have a specific timeline for the fix going live due to its complexity, but please feel free to write back in case you see this more than .02% of the time via your monitors or other sources, and want to confirm that it is the same issue. We’ll be happy to investigate and advise if there are other contributing causes we can see.

+1. This is happening on multiple sites we have on Netlify. Example request ID 01FRG24WSCZMX1NP4HGQBD82N3.


Thanks for letting us know @gsjen123. We have shared this information internally with the team that is investigating.

I’ve heard from a rep internally that they haven’t actually identified the cause of this issue, which is why no one in this thread or others has actually been able to suggest a way to mitigate it.

I’ve noticed that we have one Netlify app that this happens constantly for, and another that never has the issue. The only thing that I’ve come up with is that the app that has issues uses the netlify.toml file to perform some redirects (and a /* rewrite), whereas the one that doesn’t have the issue uses a _redirects file and only includes a single /* rewrite with no other redirects.

I’m going to experiment with this and see if it improves the situation. It would be interesting to see what others have in their netlify.toml/_redirects to see if we can find a pattern.

Thanks for the update @jared.

We have about 100 sites on Netlify, and I’m pretty sure all of them are affected by this issue. Almost all use a _redirects (and _headers) file; none use netlify.toml.

We haven’t found any pattern yet that would indicate what the cause could be, but we’ll keep monitoring and update here if we find anything.