MySQL Flexible Server capabilities API returning HTTP 500 x-ms-failure-cause:service for 5+ days - subscription blocked

Question

MySQL Flexible Server capabilities API returning HTTP 500 x-ms-failure-cause:service for 5+ days - subscription blocked

James MacDonald 20

We have been unable to create any Azure Database for MySQL Flexible Server since May 28, 2026. The issue affects our subscription across all regions, SKUs, tiers, and resource groups. The root cause identified via --debug output is the capabilities endpoint returning HTTP 500 with x-ms-failure-cause: service before server creation is even attempted.

Affected subscription: [SUBSCRIPTION-ID]

Failing API endpoint:

GET https://management.azure.com/subscriptions/[SUBSCRIPTION-ID]/providers/Microsoft.DBforMySQL/locations/eastus2/capabilities?api-version=2025-06-01-preview
Response: HTTP 500
x-ms-failure-cause: service

What we have tried:

Multiple regions: eastus, eastus2, westus, westus2, northcentralus, northeurope, westeurope
Multiple SKUs: Standard_B1ms, Standard_D2ads_v5, Standard_D2ds_v4
Multiple tiers: Burstable, GeneralPurpose
Multiple resource groups across multiple subscriptions
Both Azure CLI and Azure Portal
Provider registration confirmed: Microsoft.DBforMySQL is Registered
Confirmed via --debug: authentication succeeds, resource group check succeeds, name availability check succeeds — failure occurs specifically on capabilities API call

Also failing: PITR restore on an existing MySQL 8.0.44 Flexible Server fails with InternalServerError regardless of restore time, SKU, or method used.

Business impact: We have a MySQL 8.0 to 8.4 major version upgrade planned with a July 31, 2026 deadline. We cannot validate our rollback procedure without being able to provision a test server. A logical backup is ready but no way to test restore.

All tracking IDs collected since May 28:

66cfc7c4-1083-42c6-bfc8-3f1559926e07
aaee7a2b-96d1-44ce-a625-214022dc8bdc
74e267db-3cc1-422a-afd9-da94c3c3939c
935ccd52-2263-4405-8e41-e6ea92f9451c
d85723b6-7fb8-42af-b22c-2f751ed19365
72562237-84e2-4805-9215-d72b6f49c50b
c0066818-f9d6-440b-8bf7-a20a72d4ebe9
c1da8583-692a-494a-8447-d0e5e11a645b
72704b76-3a3f-4cdd-b5b0-8f8c70b4d4be
81436e73-72ff-4d8f-9623-1c5ed087aee1
1de09678-809c-45f7-8537-361e3643f846
dab24176-6ad0-49a8-a855-c9b60cb401c7

Debug snippet showing exact failure:

Request URL: .../providers/Microsoft.DBforMySQL/locations/eastus2/capabilities?api-version=2025-06-01-preview
Response status: 500
x-ms-failure-cause: service
Response: {"error":{"code":"InternalServerError","message":"An unexpected error occured while processing the request."}}

Retried 4 times automatically, all returned HTTP 500.We have been unable to create any Azure Database for MySQL Flexible Server since May 28, 2026. The issue affects our subscription across all regions, SKUs, tiers, and resource groups. The root cause identified via --debug output is the capabilities endpoint returning HTTP 500 with x-ms-failure-cause: service before server creation is even attempted.

Affected subscription: [SUBSCRIPTION-ID]

Failing API endpoint:

GET https://management.azure.com/subscriptions/[SUBSCRIPTION-ID]/providers/Microsoft.DBforMySQL/locations/eastus2/capabilities?api-version=2025-06-01-preview
Response: HTTP 500
x-ms-failure-cause: service

What we have tried:

Multiple regions: eastus, eastus2, westus, westus2, northcentralus, northeurope, westeurope
Multiple SKUs: Standard_B1ms, Standard_D2ads_v5, Standard_D2ds_v4
Multiple tiers: Burstable, GeneralPurpose
Multiple resource groups across multiple subscriptions
Both Azure CLI and Azure Portal
Provider registration confirmed: Microsoft.DBforMySQL is Registered
Confirmed via --debug: authentication succeeds, resource group check succeeds, name availability check succeeds — failure occurs specifically on capabilities API call

Also failing: PITR restore on an existing MySQL 8.0.44 Flexible Server fails with InternalServerError regardless of restore time, SKU, or method used.

Business impact: We have a MySQL 8.0 to 8.4 major version upgrade planned with a July 31, 2026 deadline. We cannot validate our rollback procedure without being able to provision a test server. A logical backup is ready but no way to test restore.

All tracking IDs collected since May 28:

66cfc7c4-1083-42c6-bfc8-3f1559926e07
aaee7a2b-96d1-44ce-a625-214022dc8bdc
74e267db-3cc1-422a-afd9-da94c3c3939c
935ccd52-2263-4405-8e41-e6ea92f9451c
d85723b6-7fb8-42af-b22c-2f751ed19365
72562237-84e2-4805-9215-d72b6f49c50b
c0066818-f9d6-440b-8bf7-a20a72d4ebe9
c1da8583-692a-494a-8447-d0e5e11a645b
72704b76-3a3f-4cdd-b5b0-8f8c70b4d4be
81436e73-72ff-4d8f-9623-1c5ed087aee1
1de09678-809c-45f7-8537-361e3643f846
dab24176-6ad0-49a8-a855-c9b60cb401c7

Debug snippet showing exact failure:

Request URL: .../providers/Microsoft.DBforMySQL/locations/eastus2/capabilities?api-version=2025-06-01-preview
Response status: 500
x-ms-failure-cause: service
Response: {"error":{"code":"InternalServerError","message":"An unexpected error occured while processing the request."}}

Retried 4 times automatically, all returned HTTP 500.

SAI JAGADEESH KUDIPUDI 3,640 Reputation points Microsoft External Staff Moderator

2026-06-02T16:53:06.2266667+00:00

Hi @James MacDonald ,
Could you please share requested details in private message
SAI JAGADEESH KUDIPUDI 3,640 Reputation points Microsoft External Staff Moderator

2026-06-17T18:01:58.4+00:00

Hi @James MacDonald ,
Could you please provide an update on the requested details or let me know if you have made any progress? Your input will help us move forward effectively.

Once we receive your response, we will review the information and assist you in deploying the MySQL Flexible Server successfully.

Thank you for your time and cooperation. Please feel free to reach out if you have any questions or need further assistance.

Answer accepted by question author

SAI JAGADEESH KUDIPUDI 3,640 Microsoft External Staff Moderator

Hi @James MacDonald ,

Thank you for your patience.

Based on our investigation, the issue was not related to the server name itself.
The failure occurred at the subscription level during capability validation, which can result in backend errors before deployment begins.

We confirmed this by testing:

The same deployment failed in the original subscription
The same server name worked successfully in another subscription
Deployment via Azure CLI also succeeded

The deployment was successful after switching to a different subscription, confirming a subscription-specific backend constraint.

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.

0 comments

1 additional answer

Your answer

SAI JAGADEESH KUDIPUDI 3,640 Reputation points Microsoft External Staff Moderator

2026-06-02T16:53:06.2266667+00:00

Hi @James MacDonald ,
Could you please share requested details in private message
SAI JAGADEESH KUDIPUDI 3,640 Reputation points Microsoft External Staff Moderator

2026-06-17T18:01:58.4+00:00

Hi @James MacDonald ,
Could you please provide an update on the requested details or let me know if you have made any progress? Your input will help us move forward effectively.

Once we receive your response, we will review the information and assist you in deploying the MySQL Flexible Server successfully.

Thank you for your time and cooperation. Please feel free to reach out if you have any questions or need further assistance.

Answer 1

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.DBforMySQL is 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
```
- After re-registration, retry a simple capabilities call or a minimal server create to see if behavior changes.
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.DBforMySQL return HTTP 500 with x-ms-failure-cause: service across all tested regions.
    - New server creation and PITR restores both fail with InternalServerError.
    - Include the subscription ID and the list of tracking IDs collected.
- 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.
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
```
- Attach these outputs, along with the tracking IDs and timestamps, to the Azure support ticket so the product team can correlate with backend logs.
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.

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: