This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(48, 93%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ER%3C/text%3E%3C/svg%3E)
Hi,
Today I'm experiencing very frustrating webapp behavior for the second time in a few months.
It prevents my customers from accessing the web api and it prevents me from publishing updates.
Situation
It's an S2 - 'always on' production web application with a custom domain with SSL certificate allowing only HTTPS.
Up until today I had no problems for several months. It just worked perfectly. So I don't believe configuration problems are in play.
Problem
From different computers (wired and wireless) and my phone (4G) I try accessing both the custom domain url and the azurewebsites.net url.
Sometimes I get the expected response (200 with the expected content), sometimes I get a 404.
This behavior seems to be random, which is visible when frequently refreshing the web page with F5.
As indicated, I see this behavior on unrelated computers and my phone, which to me indicates that the problem is not on either computer and not even in my network because my phone connects on 4G.
I tried to re-publish the webapp (with some more diagnostic logging in it) from Visual Studio (webdeploy) but that fails with a timeout.
-> Could not complete the request to remote agent URL 'https://mywebapp.scm.azurewebsites.net/msdeploy.axd?site=MYWEBAPP'. The operation has timed out
Even Kudu gives me a 404 once in a while.
Publishing with FTP took forever, but it worked...
The new diagnostics appeared in the log file, but gave no new insights.
I had this problem once, several months ago. I wasn't able to fix it at that time, and when I returned to the problem the next day it was gone...
Everything worked just fine without me making any changes in the Azure portal and have done so until today.
At this point I'm hoping the problem will simply vanish as it did then, because I have no clue what this can be and what I can do about it.
In the Azure portal I see no problems.
In the log files I see no problems.
The web application doesn't crash and shows no problems in it's own log file.
It looks like a routing problem somewhere, but I'm not able to pinpoint.
I've checked name resolving.
I've done route tracing.
I checked DNS propagations.
It seems the requests simply aren't delivered to my webapp.
It's ridiculous and I have no clue what to do about it.
To me, this Azure webapp is unreliable and I perhaps I have to reconsider Azure as the platform of choice.
Because with problems like these and no clue (or tools) to do anything about it, it will be impossible to service my customers in a reliable way.
I hope someone might have a clue to what I'm doing wrong or what the cause might be.
Thanks,
Richard
Hi @Richard ,
I hear your frustration and apologies that you've experiencing intermittent problems with your app service. In order to determine what's going on, we'd like to work more closely with you. Please send us an email to AzCommunity[at]microsoft[dot]com ATTN Ryan. Make sure you include your subscription id and affected app service in your email.
Regards,
Ryan
I have a few thoughts for you.
Hi Dave,
Thanks for replying.
To answer your questions:
This morning I found what I hoped for and was afraid of: the web app worked just fine again.
No problems with the web API and no problems with web-deploy from VS2019.
So, I won't be able to see the effect of toggling the 'always on' option.
The web app runs just fine at this moment, which is good, but it still worries me that such a problem can suddenly surface and the only thing I can do is wait for it to pass.
If the problem does resurface I will certainly give the 'always on' toggle a try.
Cheers,
Richard
Do you have any slots configured? There is a mechanism available that can route traffic to a different slot. This could trick you into thinking you're hitting one app but you're actually hitting the slot. Its called traffic percentages and controls which slot gets what percentage of incoming requests.
Let me know how it goes and what you find.
Hopefully this helps you find the issue.
I just double-checked; For this webapp there are no slots or other multi-instance features configured.
Thanks for your insight on traffic percentages.
Good to know for when I'm going to take a look at implementing slots.
Cheers,