An Azure managed PostgreSQL database service for app development and deployment.
Issue with posting answer
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
I am encountering a 'SkuNotAvailable' error when attempting to deploy an Azure Database for PostgreSQL flexible server using an ARM template. The deployment process fails during the creation of a new server, even though the requested SKU appears to be available in the region. Also, a new behavior, has been working fine for months, and this started a few days ago.
Azure Database for PostgreSQL flexible server, region not specified in detail.
Everything we could think of.
I am seeking assistance to understand why the 'SkuNotAvailable' error occurs despite the SKU being listed as available, and how to resolve this issue to successfully deploy the server.
An Azure managed PostgreSQL database service for app development and deployment.
Issue with posting answer
Issue with posting answer
Likely cause: this error is usually a capacity/placement mismatch (SKU + region + availability-zone/HA combination) rather than a template syntax issue, especially when behavior changed recently.
Validation checks
Hi Steve Mordue & thx for join me at Q&A platform,
important detail here is that the same ARM deployment worked for months and only started failing recently. That makes a regional capacity or provisioning issue worth investigating, rather than assuming your template is incorrect.
SkuNotAvailable doesn't always mean the SKU is absent from the regional catalog. A SKU can be listed as supported but still be unavailable for new deployments due to capacity, availability-zone constraints, or subscription-specific restrictions.
I'd try creating the same PostgreSQL Flexible Server SKU manually in the Azure Portal, using the same subscription, region, availability zone, and HA configuration. If that also fails, it helps isolate the problem from ARM.
Check the deployment's full error details, including any nested messages, and compare results with a different availability zone or SKU. Given the recent change in behavior, I'd open an Azure Database for PostgreSQL support case and request a regional capacity/provisioning investigation. Include the exact SKU, region, zone, subscription ID, failed deployment correlation IDs, and UTC timestamps.
The regional SKU listing alone isn't proof of current provisioning capacity. Only Microsoft can confirm whether this is a capacity restriction or a service-side regression.
Best regards,
Alex Burlachenko
💬 P.S. Did this help? Mark it as the solution: it keeps me motivated!
➕ Follow me on Q&A for more answers
📝 And feel free to visit my blog → https://ctrlaltdel.blog/