We are experiencing an issue where adding custom subdomains to Azure Static Web Apps consistently transitions into a "Validation failed" or an unrecoverable "Unknown error" loop during the initial verification / certificate provisioning stage, even when valid CNAME records are present in Azure DNS. Intriguingly, if left completely untouched for a period of time, the platform's background control plane eventually hooks up, completes the handshake, and transitions the state to "Validated" automatically after approximately 5 to 10 background retry attempts without any administrative interference on our end. Steps to Reproduce / Observed Behavior:
- An explicit CNAME record for a subdomain (e.g.,
platform or learner-app) is mapped in our Azure DNS Zone pointing directly to the standard .`azurestaticapps.net` deployment hostname.
- The domain is attached to the corresponding Static Web App via the portal/CLI.
- Instead of parsing the CNAME immediately, the custom domain blade freezes at the "Retrieving validation token" or throws a generic red "Unknown error" UI banner.
- If we trigger a deletion via the Azure CLI (
az staticwebapp hostname delete), the hostname frequently hangs indefinitely in a "Deleting" loop, implying a control-plane deadlock.
- If the resource is left alone in its failed/stuck state, the system suddenly succeeds on its own later, generating the managed certificate after multiple internal timeout intervals.
Requested Action: Please review the internal asynchronous control plane logs for our Static Web Apps subscription during custom domain provisioning. It appears that the edge certificate generation validation pipeline is encountering caching or timing race conditions with internal Azure DNS routing resolution before successfully assigning the free managed SSL certificate.We are experiencing an issue where adding custom subdomains to Azure Static Web Apps consistently transitions into a "Validation failed" or an unrecoverable "Unknown error" loop during the initial verification / certificate provisioning stage, even when valid CNAME records are present in Azure DNS.
Intriguingly, if left completely untouched for a period of time, the platform's background control plane eventually hooks up, completes the handshake, and transitions the state to "Validated" automatically after approximately 5 to 10 background retry attempts without any administrative interference on our end.
Steps to Reproduce / Observed Behavior:
- An explicit CNAME record for a subdomain (e.g.,
platform or learner-app) is mapped in our Azure DNS Zone pointing directly to the standard .`azurestaticapps.net` deployment hostname.
- The domain is attached to the corresponding Static Web App via the portal/CLI.
- Instead of parsing the CNAME immediately, the custom domain blade freezes at the "Retrieving validation token" or throws a generic red "Unknown error" UI banner.
- If we trigger a deletion via the Azure CLI (
az staticwebapp hostname delete), the hostname frequently hangs indefinitely in a "Deleting" loop, implying a control-plane deadlock.
- If the resource is left alone in its failed/stuck state, the system suddenly succeeds on its own later, generating the managed certificate after multiple internal timeout intervals.
Impacted Resources Examples:
Requested Action:
Please review the internal asynchronous control plane logs for our Static Web Apps subscription during custom domain provisioning. It appears that the edge certificate generation validation pipeline is encountering caching or timing race conditions with internal Azure DNS routing resolution before successfully assigning the free managed SSL certificate.