We are seeing some delays in Time To First Byte because OCSP stapling is not active on Azure Web Apps SSL endpoints.
This causes our clients' browsers to call the issuing CA's endpoint before SSL negotiation can really begin.

Stapling would save the client browser from having to make an extra request to the CA checking if the certificate has been revoked.

There is also a potential privacy issue for our clients that the CA will be able to log these requests. If the web server takes care of OCSP on the other hand no requests will be sent from the client to the CA.

The wikipedia article on OCSP stapling explains things pretty well.
https://en.wikipedia.org/wiki/OCSP_stapling

Running webpagetest.org against your site with the browser set to firefox shows the OCSP calls to the CA.

The remote debugging function will be more useful, if there is one of the function (or both) I mention below.

1. Enable remote debugging for the "scheduled" WebJob
2. Automatically attach the debugger when starting the "continuous" WebJob

If we want to remote debug a WebJob using Visual Studio, it is only supported for the "continuous" WebJob.
Thus, if we want to debug a scheduled WebJob, we have to set the WebJob as "continuous", even if it is a "scheduled WebJob".

However, when we remote debug the continuous web job, we have to start the WebJob before attaching the debugger so there is a little time lag.
If the WebJob ends so fast, then it is hard to attach the debugger because of the time lag.
(I know the "continuous" WebJob never ends, but this is a scenario that we set a "scheduled WebJob" as a "continuous WebJob" to remote debug)

We host some services and our clients point to them using CNAMEs. We want to move from cloud services to web apps but right now it's a massive pain. We have to notify all our clients to first add TXT records for approval, then approve and then ask all of them to switch to new CNAME. Asking clients to do any DNS changes is already a problem and now we have to coordinate with all of them to first add txt records and then point to new service. This makes the whole process really painful even though we are already running all of those domains inside cloud services. Is there any migration mechanism that is less painful than what I described?

Thanks

We make generous use of sticky slot settings. They enable us to swap code without swapping configuration.

Unfortunately for our design, diagnostic logging settings cannot be marked as sticky. Before a swap, our production slot might be logging to a production storage account, and our staging slot might be logging to a staging storage account. After the swap, production is logging to stage, and stage is logging to production. This results in muddy log files where one cannot be certain which slot was responsible for which log entries.

Please provide an option to make diagnostic logging settings sticky to a slot, so that we can count on knowing which application is responsible for writing to which log files.

Cheers!

We need a consolidated way to see near-realtime CPU and Memory consumption for each Web App per App Service Plan. This way we can quickly identify which apps are consuming the most resources (specifically CPU and Memory) in that App Service Plan.

These are the 2 scenarios we run into often:

1. We run many web apps in each App Service Plan. We don't want to pay for a new App Service Plan until all memory (or CPU) is consumed on what we currently have. I could rebalance the sites (move some to another plan) if I could easily see which sites were consuming the most resources.

2. Sometimes, a web app consumes a lot of CPU or memory. I get an alert that the App Service Plan is hitting a limit, but I need to quickly identify which Web app is consuming the resources so I can stop it or restart it.

The current way of doing this is very slow and cumbersome. If I want to see the sites using the most memory, in Metrics (App Service Plan), I have to add every site to the chart, uncheck CPU for each site, then hover over the chart. Then I visually sort them in my mind.

Ideally, I could instead click on App Service Plan, Consumption and see a list of all web apps with CPU and memory consumption and the ability to sort it by either.

There are many reasons you may want to have a static IP address for outbound connections. For example, you may be accessing a system which requires you to whitelist IP address in a firewall, such as SQL Database or an external service.

Currently, the only way to get a static IP address for outbound connections is to use App Service Environment. App Service Environments are quite complex, and has a very high price tag. You need at least 4 instances, 2 of which must be P2, meaning you'll pay at least 1000 EUR/month. Paying 1000 EUR/month just because you want a static IP address is obviously ridiculous.

I'm looking forward to being able to use a static IP address without an App Service Environment.

Currently 503 errors (service unavailable) present a blank white page with "service unavailable" to the users which is far from professional for us. It would be far better if we could provide a custom 503 page which would include a logo etc., and some text along the lines of "We apologise for the inconvenience, we are working on it. These issues usually resolve in about five minutes. please contact support for further help if required." or something similar.... This error might be caused by Azure network issues, so away from the web app instance.

It would also be helpful if this were possible for 403s as well. However 503 is the most important.

I have raised this idea before, but it seems to have disappeared.

I am pretty surprised that we cannot do this already.

Thanks.

We've recently suffered a 3 hour outage on our web app due due to the process servicing the web app continuously crashing. After escalating the issue and working with an escalation engineer we have not been able to diagnose the cause (access violation but unfortunately the crash dump was corrupted).

However what we have learned is that even with multiple instances running if this was to happen again the unhealthy instance would not be removed from the load balancing and all requests serviced by that instance would fail. According to the escalation engineer the load balancing just detects infrastructure failures, not application health per instance.

Would it be possible to leverage the existing web test functionality to define a 'health test' for the application? If Azure detects that an instance fails the health test for an extended period of time it could tear down the instance and create a new one?

Deploying a Java application to Azure for the first time is not bad, but incremental updates are very painful. The basic functionality works, but it involved multiple steps that really shouldn't be there.

1. Every time that you want to deploy a WAR file, you have to delete the application's exploded directory (ROOT, for example). In order to do this properly, you have to stop the server first. You should be able to simply replace the WAR file (ROOT.war, for example), and have Tomcat take care of updating the application. If you have an application that is large or has a lot of files this process can take your application out of service for a long time (20+ minutes to delete all the files over FTP in my case).

2. There is no easy way to redeploy/restart Tomcat without taking the service out completely. When updating certain classes that may be loaded in memory, you may need to trigger a Tomcat redeploy.

3. When deploying WAR files over GIT (or any of the other deployment methods), it looks like Azure SOMETIMES attempts to have Tomcat deploy the newly uploaded file before it is finished uploading. This results in a partial application deploy and requires to you to restart the server anyway to get it to load properly.

Deploying exploded WAR files via a repository seems to work OK, but classes don't always get reloaded if they change.

4. The Catalina and other tomcat generated logs seem to be locked by the OS (even for reading), and are unavailable via FTP until the site is stopped. This makes debugging issues very difficult, as errors can't be read while the server is running.

Would it be possible to set up Alerts and Webhooks for when Azure changes the underlying machines that run each App Service?

We run a website which (as part of it's operation) tracks the machines it is running on. Through this we can see that every now and again the underlying machine changes with no apparent reason. We assume that this is because the underlying machine has been patched and needs a reboot (or something like that) and thus our website has been provisioned to a different machine. All of that is fine, we understand this is all part and parcel of using Azure App Services. It would just be great to be able to configure an alert to be notified when this happens.

We just want to be able to tell the difference between a standard maintenance move and a move perhaps instigated due to issues with our site. Also, I'm sure there are plenty of web systems out there that need some "initialisation" work when deployed to a new machine. If we could hook up a Webhook when this happens that could take care of that.

Thanks.