Azure Front Door 499 responses from pop_s EWR

Hello @EJ Marmonti ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I understand that your Azure Front Door is reporting a lot of 499 responses from the EMR pop location, and you would like to know what could cause this behavior.

As per the Azure Front Door metrics and logs document,

The HTTP status code returned from Azure Front Door. If the request to the origin timed out, the value for the HttpStatusCode field is 0. If the client closed the connection, the value for the HttpStatusCode field is 499.

I checked internally and found that this new http status code of 499 could be due to the ongoing rollout of new software for POPs. The new software returns a 499 for client disconnections whereas the previous software returned a 50x error.

You can try to increase the Azure Front Door timeout setting and check if that helps fix the issue.

You can increase the default timeout to up to 4 minutes (240 seconds). To configure the setting, go to overview page of the Front Door profile. Select Origin response timeout and enter a value between 16 and 240 seconds.

Refer: https://video2.skills-academy.com/en-us/azure/frontdoor/troubleshoot-issues#troubleshooting-steps

Regards,

Gita

Hello,

I understand that a 499 translates to a client disconnect. The timeout is already set to 4 minutes / 240 seconds. The thing is, it looks like most of these are disconnecting after 0 seconds from EWR.

If I look over the past 7 days at traffic, I can see that EWR responded with a 499 on almost 6k requests where timeTaken_d was 0. This number id drastically different from the other pop locations:

Further, if I query the same thing, except where timeTaken_d > 0, the results looks more evenly distributed across the 8 pop locations:

Additionally, if I generate a timechart with data since January with the above query (where timeTaken_d == 0), it tells me that these 499's at EWR started around 7/10/2023, and as you can see it has significantly more 499 responses than the other pop locations:

Lastly, and just for reference, here is a chart where I'm not filtering for a specific httpStatusCode, nor a timeTaken_d value, and it's just to prove that we do have all of this data in the logs going back to January 2023, alas showing the 499's where timeTaken == 0 began showing up in July:

So it still feels like there is maybe something going on with EWR when you consider that timeTaken_d == 0. Could it be that maybe there is some other setting I'm missing that is causing clients to terminate the moment it connects? I'm trying to understand what would cause timeTaken_d to be 0.

Thank you

Thank you for the details, @EJ Marmonti .

To find out the exact root cause behind this issue, we may need to look into the backend logs and would need access to your resources for further investigation. Hence, if you have a support plan, I request you file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.

In case you need help with a one-time free technical support, please send an email with subject line "ATTN gishar | Azure Front Door 499 responses from pop_s EWR" to AzCommunity[at]Microsoft[dot]com with the following details, I will follow-up with you.

• Reference this Q&A thread
• Your Azure Subscription ID

Note: Do not share any PII data as a public comment.

We will post a summarized answer once the issue is resolved.

Regards,

Gita

@EJ Marmonti , Could you please provide an update on this post?

Hello,

I will do some additional troubleshooting in our application with development to see if I can narrow this down to a potential timeout misconfiguration in the application. Once I have that information / if that doesn't solve it, I'll open a ticket through our support plan.

Thanks