![](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(112.00000000000001, 22%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJM%3C/text%3E%3C/svg%3E)
Azure Database for MySQL
An Azure managed MySQL database service for app development and deployment.
![](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(208, 49%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESJ%3C/text%3E%3C/svg%3E)
The behavior described matches a backend service issue or a subscription/region constraint on Azure Database for MySQL – Flexible Server rather than a client or configuration problem. The capabilities call failing with HTTP 500 and x-ms-failure-cause: service is a service-side fault and cannot be fixed from the client side.
From the available guidance, the only supported remediation paths when provisioning is blocked at the platform level are:
- Validate that the subscription is correctly registered for MySQL
- Confirm
Microsoft.DBforMySQLis registered (already done). If needed, re-register using either:- Azure portal: Subscription → Resource providers → search for
Microsoft.DBforMySQL→ Re-register. - Azure CLI:
az provider register --namespace Microsoft.DBforMySQL - Azure PowerShell:
Register-AzResourceProvider -ProviderNamespace Microsoft.DBforMySQL
- Azure portal: Subscription → Resource providers → search for
- After re-registration, retry a simple capabilities call or a minimal server create to see if behavior changes.
- Confirm
- Check for regional or subscription constraints
- When a subscription is blocked from provisioning in a region or capacity is constrained, the documented guidance is to open a support request and have the service team review the subscription and region access on a case-by-case basis.
- Use the Azure portal to open a support request with:
- Issue type: Service and subscription limits (or equivalent) for Azure Database for MySQL – Flexible Server.
- Clearly state that:
- Capabilities API calls for
Microsoft.DBforMySQLreturn HTTP 500 withx-ms-failure-cause: serviceacross all tested regions. - New server creation and PITR restores both fail with
InternalServerError. - Include the subscription ID and the list of tracking IDs collected.
- Capabilities API calls for
- If the subscription is part of an Azure program offer (Azure Pass, Azure for Students, Visual Studio/MSDN, MPN, BizSpark, Startups/Sponsorship, etc.), note that these offers can have restricted region access. In such cases, explicitly request region access or capacity for the regions and vCore SKUs required for testing and rollback validation.
- Treat this as a provisioning/capacity issue for escalation
- The documented pattern for unresolved provisioning issues is to open a Region access or capacity support request under Azure Database for MySQL – Flexible Server and specify:
- Required regions.
- Required vCore counts/SKUs (for example, Standard_B1ms, Standard_D2ads_v5, Standard_D2ds_v4).
- Reference that the failure occurs before server creation (capabilities endpoint) and that PITR restore also fails, so the issue is not tied to a specific server or template.
- The documented pattern for unresolved provisioning issues is to open a Region access or capacity support request under Azure Database for MySQL – Flexible Server and specify:
- For CLI troubleshooting and evidence
- Use the deployment operations logs to provide additional evidence to support:
- List deployment operations for the failed MySQL Flexible Server deployment in the resource group:
az deployment operation group list \ --resource-group <rg-name> \ --name <deployment-name> - Extract request and response payloads for the MySQL Flexible Server deployment operations:
az deployment operation group list \ --name <deployment-name> \ -g <rg-name> \ --query [].properties.request az deployment operation group list \ --name <deployment-name> \ -g <rg-name> \ --query [].properties.response
- List deployment operations for the failed MySQL Flexible Server deployment in the resource group:
- Attach these outputs, along with the tracking IDs and timestamps, to the Azure support ticket so the product team can correlate with backend logs.
- Use the deployment operations logs to provide additional evidence to support:
- Interim mitigation for backup/rollback validation
- Because both new server creation and PITR restore are failing with
InternalServerError, there is no documented client-side workaround to force a successful Flexible Server deployment while the capabilities endpoint is returning 500. - The only path to restore service for testing the 8.0→8.4 rollback is through Azure Support and the MySQL Flexible Server product team resolving the backend or subscription-level issue.
- Because both new server creation and PITR restore are failing with
Given the duration (5+ days), the HTTP 500 on capabilities, and the impact on both create and restore, this must be treated as a service incident or subscription-level block that requires an Azure Support case with the MySQL Flexible Server team, using the “Service and subscription limits / Region access” and “provisioning issues” flows described in the documentation.
References:
- Resolve capacity errors for Azure Database for MySQL
- Troubleshoot Azure Database for MySQL - Flexible Server CLI errors
- Azure Database for MySQL Flexible Server September 2025 version release notes
- Azure Database For MySQL Flexible Server February 2025 Version Release Notes
- Troubleshoot Azure Database for MySQL - Flexible Server backup (preview)
- Can't create Azure SQL server via Azure portal - Microsoft Q&A
- Azure Deployment Takes 70 Minutes to Fail with Obscure Error - Microsoft Q&A