Azure Database for MySQL Flexible Server — backend InternalServerError blocks ALL provisioning (reproducible, not config/quota related)

Question

Azure Database for MySQL Flexible Server — backend InternalServerError blocks ALL provisioning (reproducible, not config/quota related)

Soller, Cathy 20

I'm unable to create any Azure Database for MySQL Flexible Server on my subscription. This is not a usage or configuration error — Azure's own backend returns an HTTP 500 (InternalServerError) when listing available MySQL SKUs/capabilities for the subscription, which happens before server name, SKU, or network validation is even reached.

Reproduction:

Tested with 5+ different server names across multiple regions. All fail at the identical point in the Azure CLI's MySQL SKU-listing call (location_based_capabilities operation):

azure.core.exceptions.HttpResponseError: (InternalServerError) An unexpected error occured while processing the request. Tracking ID: '5c206194-0fe2-4b5a-a130-537a4f552770'

Confirmed in two separate regions, each with its own Tracking ID:

eastus2 — Tracking ID: 5c206194-0fe2-4b5a-a130-537a4f552770
eastus — Tracking ID: 9123fd68-b620-49d7-b0a0-3ee8fc53295b

What I've already ruled out:

Microsoft.DBforMySQL resource provider shows "Registered" (verified via az provider show --namespace Microsoft.DBforMySQL)
Not a naming collision — tried 5+ unique names
Not region-specific — same failure in multiple regions
Not a VNet/subnet config issue — error occurs before network validation runs

Command used (sanitized):

bash

az mysql flexible-server create \
  --resource-group "rg-pbb-wp-stg" \
  --name "<unique-name>" \
  --location "<region>" \
  --admin-user "civicrmadmin" \
  --sku-name Standard_B1ms \
  --tier Burstable \
  --version 8.0.21 \
  --storage-size 32 \
  --vnet "vnet-pbb-wp-stg" \
  --subnet "snet-mysql"

Ask: Could someone from the Azure Database for MySQL team take a look at why the capabilities/SKU lookup is failing at the subscription level? This is blocking all deployment of MySQL Flexible Server resources, with no workaround available since the failure happens pre-validation. Happy to provide additional Tracking IDs or run further diagnostics — this has been an open, unresolved issue for several months (related prior ticket: TrackingID#2604250040001180).

azure-database-mysql azure-resource-manager azure-cli

Manoj Kumar Boyini 19,345 Reputation points Microsoft External Staff Moderator

2026-06-25T11:15:09.3+00:00

Hi @Soller, Cathy

If the response helped, do "Accept Answer". If it doesn't work, please let us know the progress. All community members with similar questions will benefit by doing so. Your contribution is highly appreciated.

Answer accepted by question author

TP 161K Volunteer Moderator

Hi,

In my experience if call to Location Based Capability Set - Get REST API returns 500 InternalServerError it means the subscription is blocked from deploying to the region. Due to capacity constraints it is common for many subscriptions to be blocked from deploying MySQL Flexible server to the most popular regions (East US and East US 2 are among those that are blocked).

Try deploying to a less popular region, for example, US West 3. You may test using REST api with below link:

https://learn.microsoft.com/en-us/rest/api/mysql/location-based-capability-set/get?view=rest-mysql-2024-12-30&tabs=HTTP

Click Try It button, sign in, select your directory, for capabilitySetName enter default , for locationName enter the region code (e.g. westus3, westus2, centralus, eastus, etc. ), scroll down and click Run button. If you get InternalServerError it means subscription is blocked for that region, if you get a list of supported editions, skus, etc., then that means region is permitted.

I first noticed this some months ago when investigating via portal. If portal shows "Subscription '<subscription>' is not allowed to provision in '<region>' you'll see the underlying REST API call returns 500 error. That's how the portal knows to display the error. Using 500 error in this way is generally not "standard" practice, but it seems to be how this api method works.

What you can do is submit a free Service and subscription limits (quotas) request via portal and select Quota type: Azure Database for MySQL Flexible server, on Additional details tab click Enter details, Quota type: Region access, select the region you need, enter vCores requested, etc. Please note your request for region access may be denied.

How to Create an Azure support request

https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request#open-a-support-request-from-the-global-header

If you have trouble creating the support request please let me know and I'll post detailed, specific to MySQL Flexible instructions including screenshots.

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP

TP 161K Reputation points Volunteer Moderator

2026-06-23T16:48:49.2633333+00:00

@Soller, Cathy Any update?
Cathy Soller 0 Reputation points

2026-06-25T02:27:56.65+00:00

@TP sorry, I do this as a volunteer in my "free" time. I already created aa ticket, two of them actually, the response was because we are a non-profit on aa grant we don't have support even though it looked to me like aa subscription issue.

I tried the REST API URL you provided and I got a 500 on everything except westus2. That is probably the ONLY one I didn't try to deploy to before. I was just able to successfully deploy. Makes no sense with an east coast address we have to deploy to the westus2 but i'll take it for now. Thanks for the assist!!!!
TP 161K Reputation points Volunteer Moderator

2026-06-25T02:38:39.9966667+00:00

@Soller, Cathy @Cathy Soller You are welcome. Please sign in using your "Soller, Cathy" account and click Accept Answer on my answer.

Thank you.
Soller, Cathy 20 Reputation points

2026-06-25T11:49:38.9066667+00:00

@TP oh the joy of multiple Microsoft profiles. I had to log in on the same computer I posted this from to be able to accept the answer :). Thanks again!

2 additional answers

Your answer

Manoj Kumar Boyini 19,345 Reputation points Microsoft External Staff Moderator

2026-06-25T11:15:09.3+00:00

Hi @Soller, Cathy

If the response helped, do "Accept Answer". If it doesn't work, please let us know the progress. All community members with similar questions will benefit by doing so. Your contribution is highly appreciated.
TP 161K Reputation points Volunteer Moderator

2026-06-23T16:48:49.2633333+00:00

@Soller, Cathy Any update?
Cathy Soller 0 Reputation points

2026-06-25T02:27:56.65+00:00

@TP sorry, I do this as a volunteer in my "free" time. I already created aa ticket, two of them actually, the response was because we are a non-profit on aa grant we don't have support even though it looked to me like aa subscription issue.

I tried the REST API URL you provided and I got a 500 on everything except westus2. That is probably the ONLY one I didn't try to deploy to before. I was just able to successfully deploy. Makes no sense with an east coast address we have to deploy to the westus2 but i'll take it for now. Thanks for the assist!!!!
TP 161K Reputation points Volunteer Moderator

2026-06-25T02:38:39.9966667+00:00

@Soller, Cathy @Cathy Soller You are welcome. Please sign in using your "Soller, Cathy" account and click Accept Answer on my answer.

Thank you.
Soller, Cathy 20 Reputation points

2026-06-25T11:49:38.9066667+00:00

@TP oh the joy of multiple Microsoft profiles. I had to log in on the same computer I posted this from to be able to accept the answer :). Thanks again!

Answer 1

Hi @Soller, Cathy

it looks like you’re hitting a 500 InternalServerError in the location_based_capabilities call when trying to list SKUs—which indicates the MySQL control-plane isn’t returning capabilities for your subscription. Since you’ve already verified provider registration, tried multiple names and regions, and ruled out quotas and network, here’s what you can do:

Capture detailed logs • Run: az monitor activity-log list --correlation-id <Tracking ID> • Check for any correlated failures or insights around the time of your CLI call.

Retry the operation • Sometimes control-plane errors are transient. Wait a few minutes and retry the same az mysql flexible-server create command.

Verify region support and capacity • Confirm Flexible Server is supported in your target regions (East US/East US 2 are normally supported). • If you suspect regional capacity constraints, submit a support request under “Service and subscription limits (quotas)” specifying the region and SKU.

Re-register the resource provider • As a sanity check, run: az provider register --namespace Microsoft.DBforMySQL • Ensure it returns “Registered” before retrying.

Have you tried in another region Ex: West US 3 or Central US, If the issue still persists please let us know.
Do you have Support Plan?

References:
https://learn.microsoft.com/azure/mysql/flexible-server/how-to-troubleshoot-cli-errors#error-codes https://learn.microsoft.com/azure/mysql/flexible-server/resolve-capacity-errors#regional-constraints

Answer 2

Hi Cathy,

Based on what you shared, this does look more like a backend/subscription-level issue than a normal MySQL Flexible Server configuration issue.

Since the failure happens during the capabilities/SKU lookup, before name, SKU, or networking validation, I would first test the SKU call directly:

az mysql flexible-server list-skus --location eastus2 -o table
az mysql flexible-server list-skus --location eastus -o table

If those commands also return InternalServerError, then this is likely not related to the server name, VNet, subnet, or selected SKU. It needs to be checked by Azure support/product engineering using the Tracking IDs.

I would include these items in the support request:

Subscription ID

Region tested

CLI command and timestamp in UTC

Tracking IDs:

eastus2: 5c206194-0fe2-4b5a-a130-537a4f552770

  eastus: `9123fd68-b620-49d7-b0a0-3ee8fc53295b`
  
  Prior ticket: `2604250040001180`
  
  Confirmation that `Microsoft.DBforMySQL` is registered

Also check Azure Service Health for any MySQL Flexible Server advisories affecting the subscription/regions, but if this has been happening for months, I would push this through the existing support ticket and ask for escalation to the Azure Database for MySQL backend team.

Docs:

Azure CLI MySQL Flexible Server commands: https://learn.microsoft.com/en-us/cli/azure/mysql/flexible-server

Create Azure support request: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

Azure Service Health: https://learn.microsoft.com/en-us/azure/service-health/overview