Type: Known Issue
Category: Umbraco Cloud > Hostnames and Downtime
Tags: azurewebsites.net, Azure default hostname, Azure URL, redirect, site down, custom domain not working, backoffice login, redirect_uri_mismatch, AADB2C90006, Umbraco.Cloud.Cms, restart, known issue
Product: Umbraco Cloud
Version: All versions
Some Umbraco Cloud projects are experiencing an issue where the website, the default umbraco.io URL or the backoffice login suddenly sends visitors to an address ending in .azurewebsites.net instead of your own domain. Here's what we know and how to get your site back.
Status: Workaround available. Our development team is aware of the issue and is working on it. Restarting the affected environment brings the site back.
Symptoms
You may see one or more of the following, often without having deployed or changed anything:
Visiting your domain redirects to an address like
https://www.{guid}.azurewebsites.net/.That address shows a "site can't be found" message or a 403 error, so the website looks like it is down.
Logging in to the backoffice fails with an error like:
Message contains error: 'redirect_uri_mismatch', error_description: 'AADB2C90006: The redirect URI 'https://{guid}.azurewebsites.net/umbraco-signin-oidc' provided in the request is not registered for the client id ...'Login works on other environments, for example Development, but not on Live.
It started overnight or after the environment was restarted automatically by the platform.
Cause
Every Umbraco Cloud environment runs on an Azure web app that has its own internal address ending in .azurewebsites.net. Normally your custom domain and the default umbraco.io URL route to that web app without the internal address ever being visible.
When this issue occurs, the routing between your domain and the web app is lost, and traffic falls back to the internal Azure address. That address is not publicly accessible, so visitors get an error. This is a platform issue. It is not caused by your code, content or DNS settings, which is also why nothing shows up in your logs.
Workaround: restart the affected environment
Restarting the environment rebuilds the routing and restores your domain.
Log in to the Umbraco Cloud Portal and open your project.
On the affected environment (usually Live), click the three dots and choose Restart.
Wait for the restart to finish, then open your domain again.
Still seeing the azurewebsites.net address after the restart? Your browser may have remembered the redirect. Open your domain in a private or incognito window, or clear the browser cache, before assuming the restart didn't work.
If the issue comes back, you can restart again. Please also let Umbraco Support know, so we can link your project to the investigation.
Reduce the risk: keep Umbraco.Cloud.Cms up to date
The Umbraco.Cloud.Cms NuGet package is one of the default packages on Umbraco Cloud projects. Several releases of it include fixes that keep the internal azurewebsites.net address hidden, for example:
Umbraco.Cloud.Cms 13.0.1, 16.0.2 and 17.0.2: keeps the internal Azure URL hidden on initial requests.
Umbraco.Cloud.Cms 13.1.0, 17.2.1 and 18.0.1: fixes cases where the internal azurewebsites.net URL could get through the Umbraco Cloud proxy.
Umbraco.Cloud.Cms 13.1.1, 17.2.2 and 18.0.2: hides the internal azurewebsites.net URL in additional cases.
We recommend checking that the package is installed in your project and updated to the latest version for your CMS major. These fixes are released for supported Umbraco versions. If your project runs a version that is no longer supported, upgrading to a supported version is the way to get them.
Still having issues?
Contact Umbraco Support if a restart doesn't bring your site back, or if the issue keeps returning. If you are chatting with Umboto, ask to be transferred to a human agent. It helps if you include:
Which environment is affected.
Roughly when the redirect started.
The azurewebsites.net address or error message you saw.
Whether you have already restarted the environment.
Recommended documentation
Major Upgrades (lists Umbraco.Cloud.Cms as a default Cloud package)
Last updated on October 27, 2026
