Azure Front Door is a Layer 7 (or HTTP(S) layer) load balancer service and provides a number of great features for better running globally available web applications. These features include SSL/TLS offloading, URL-based routing, among others. You can easily set up multiple instances of a web app hosted with Azure App Service to be the backend of a DNS endpoint managed with Azure Front Door Service.
“Service Unavailable” Problem Issue
When using Azure App Service applications as the backend for an Azure Front Door endpoint, it’s possible that when you access the Front Door Service endpoint (https://{service-name}.azurefd.net) the application may return a response with the following message:

This “Our services aren’t available right now” is a generic message that Azure Front Door Service will return if the backend endpoint (the Web App for example) is returning an HTTP 500 error or is unavailble.
Solution using ‘Always On’ feature
A common reason the “Our services aren’t available right now” error message being displayed for an Azure Front Door Service endpoint with Azure Web Apps as the backend endpoints is that the “Always On” feature is not configured. By default, an Azure App Service Web App will automatically shut down the app (or the IIS process for Windows based Web Apps), so the next time a request comes in from Azure Front Door it will time out in the backend as the application is not currently available.
To ensure that the Azure App Service Web App is running and always available to respond to incoming HTTP(S) requests, be sure to set the “Always On” configuration feature to “On“.
This feature can be turned on form the “Configuration” Settings section of the Azure App Service resource within the Azure Portal. Here’s a screenshot of what the Azure Portal UI looks like:

By setting the “Always On” feature of the App Service Web App to “On”, this will ensure that Azure will always keep an instance of the Web App running at all times. This way when a user / client hits the Azure Front Door endpoint, the backend Web App will always be ready to respond to that request without timing out. This will ensure the application is always available even during times of low usage or inactivity.
Also, be sure to set this configuration on every single Azure App Service instance configured as backend endpoints for the Azure Front Door service. Since Azure Front Door service is built to help maintain high availability in globally accessible applications, there will likely be App Service instances in multiple Azure Regions, each with their own configurations, so be sure to configure every one of those with this setting.
Or, even better, write an ARM Template for using to automate managing the App Service instances, and you’ll be able to configure it in the ARM JSON once, and then use your automated deployment process to push this change out to all your App Service instances.
Hey Chris, I’m glad I was not alone here! I have been experiencing this for some time but am using an Isolated App Service Environment (v2). Even after changing to Always On, the issue persists. Any insight as to whether or not the Isolated ASE may be contributory?
I don’t believe the ASE is interfering, but it’s possible there’s something to that idea. Make sure you can access the Web App directly from the ASE or App Service endpoint first. If you can, then it’s Front Door that’s the issue. If accessing the site directly doesn’t work, then Front Door is not the problem and it’s the App Service itself.
Also, if you find any more information out about your current scenario, please post an update here. I’d be very interested to hear the fix to your issue. Thanks!