Why are our Azure PostgreSQL quotas dangerously low? No alerts, no explanation, blocked DR process

Question

Why are our Azure PostgreSQL quotas dangerously low? No alerts, no explanation, blocked DR process

Joshua Schmidlkofer 0

On July 8, 2026, we tried to initiate a disaster recovery process and discovered we were blocked due to insufficient Azure PostgreSQL quotas. When we investigated, we found something alarming: our quota limits are drastically lower than our actual usage.

The Problem:

Production servers: CPU quota is less than 50% of what we're currently using. Our production database is actively operating above its quota.
Dev server: CPU usage is 600% higher than the quota limit. It's running massively over quota.
No alerts whatsoever: We never received any service alerts, alarms, or notifications about quota violations or enforcement. We only discovered this when we tried to scale for DR.

What I don't understand:

How did these quotas get set so low in the first place?
Were these quotas recently lowered by Microsoft, or have they always been this way?
Why didn't we get alerts when we started exceeding the quota limits (especially the dev server at 6x the limit)?
Why is the service allowing us to run above quota without notification?
How do we prevent this from happening again?
Should Azure PostgreSQL quotas be exposed in the Datadog integration so we can actually monitor them?

What we know:

The quotas were clearly inadequate relative to our actual workload
No alerts were triggered despite active violations
We have no visibility into why the quotas are set at these levels
This is now a serious business continuity concern since it blocked our DR process

Has anyone experienced this? Am I missing something about how Azure PostgreSQL quotas work? Any advice on preventing this in the future?

Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-11T23:11:57.6333333+00:00

Hi @Joshua Schmidlkofer ,

Thanks for the detailed explanation. This is expected behavior.

• vCore quota is a regional provisioning limit and is only checked during create, scale, or failover operations.

• CPU % is a runtime performance metric and is unrelated to quota consumption.

• The DR failover was blocked because the required vCore quota/SKU family quota was not available in the DR region.

• Verify the regional "cores" quota and the relevant PostgreSQL Flexible Server SKU family quota in the DR region under Usage + Quotas.

• Increase those quotas before the next DR test.

• Set quota utilization alerts (for example, 80%) and continue using server CPU alerts for performance monitoring.

this was a quota capacity issue in the DR region, not a server running over quota.
Joshua Schmidlkofer 0 Reputation points

2026-07-14T00:21:15.3433333+00:00

I failed to communicate properly in my initial message. I was too close to the problem, and I had too many hours of trying to determine how to open a ticket with the accompanying frustration.

This is not about server utilization, this is about the Azure PostgreSQL vCore provider Quotas, and nothing else.

When I failed to spawn a new instance for a DR database, I traced the Bad Request to a Quota denial. When I opened the Quota dashboard, the quota for standardedsv4family showed 100% usage, when I tried to request additional quota, the actual usage was 600% higher than the quota - literally 6x the current quota. For another standardesv3family it was only 2x the current quota. You are probably familiar with the time it takes to extend quotas. We literally spammed the quota-increase requests until it worked, while trying to get Support on the phone. Ultimately, we were able to address the immediate problem, but that has left us with a separate question: How or When did the quotas get lowered?

No one in my team lowered or adjusted quotas. They simply dropped between the last time we extended quotas and the 8th.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-18T00:06:23.1733333+00:00
Hi @Joshua Schmidlkofer ,

Thanks for the clarification. Quotas do not automatically or silently reduce over time.

• The most common causes of a quota reduction are:

Subscription offer/billing changes

Subscription transfer or migration

A Microsoft backend quota adjustment (rare) • Check Activity Log during the affected period:

Resource Provider: Microsoft.Quota

Also check Microsoft.DBforPostgreSQL

Look for quota update or subscription-related events • Review subscription lifecycle changes:

Offer type

Billing account changes

Subscription transfer/migration events • Azure Support can confirm:

Who/what changed the quota

Whether a backend adjustment occurred

The audit history for the affected SKU families • To prevent future DR failures:

Pre-allocate DR region quota for full failover capacity

Add quota validation to the DR runbook

Configure quota usage alerts (for example 70% and 90% thresholds) In short: quotas do not self-reduce. Either a subscription-level change or a backend action caused the reduction, and Azure Support can verify the exact audit trail.
Manoj Kumar Boyini 19,430 Reputation points Microsoft External Staff Moderator

2026-08-05T03:15:14.2433333+00:00

Hi @Joshua Schmidlkofer

I kindly request you to please share the details requested in the private message for further investigation.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-08-13T06:10:57.0066667+00:00

Hi @Joshua Schmidlkofer ,

Just checking in to see if the information provided earlier was helpful. Please let us know if you need any additional details or assistance, and we’ll gladly continue supporting you.

1 answer

Your answer

Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-11T23:11:57.6333333+00:00

Hi @Joshua Schmidlkofer ,

Thanks for the detailed explanation. This is expected behavior.

• vCore quota is a regional provisioning limit and is only checked during create, scale, or failover operations.

• CPU % is a runtime performance metric and is unrelated to quota consumption.

• The DR failover was blocked because the required vCore quota/SKU family quota was not available in the DR region.

• Verify the regional "cores" quota and the relevant PostgreSQL Flexible Server SKU family quota in the DR region under Usage + Quotas.

• Increase those quotas before the next DR test.

• Set quota utilization alerts (for example, 80%) and continue using server CPU alerts for performance monitoring.

this was a quota capacity issue in the DR region, not a server running over quota.
Joshua Schmidlkofer 0 Reputation points

2026-07-14T00:21:15.3433333+00:00

I failed to communicate properly in my initial message. I was too close to the problem, and I had too many hours of trying to determine how to open a ticket with the accompanying frustration.

This is not about server utilization, this is about the Azure PostgreSQL vCore provider Quotas, and nothing else.

When I failed to spawn a new instance for a DR database, I traced the Bad Request to a Quota denial. When I opened the Quota dashboard, the quota for standardedsv4family showed 100% usage, when I tried to request additional quota, the actual usage was 600% higher than the quota - literally 6x the current quota. For another standardesv3family it was only 2x the current quota. You are probably familiar with the time it takes to extend quotas. We literally spammed the quota-increase requests until it worked, while trying to get Support on the phone. Ultimately, we were able to address the immediate problem, but that has left us with a separate question: How or When did the quotas get lowered?

No one in my team lowered or adjusted quotas. They simply dropped between the last time we extended quotas and the 8th.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-18T00:06:23.1733333+00:00

Hi @Joshua Schmidlkofer ,

Thanks for the clarification. Quotas do not automatically or silently reduce over time.

• The most common causes of a quota reduction are:

Subscription offer/billing changes

Subscription transfer or migration

A Microsoft backend quota adjustment (rare) • Check Activity Log during the affected period:

Resource Provider: Microsoft.Quota

Also check Microsoft.DBforPostgreSQL

Look for quota update or subscription-related events • Review subscription lifecycle changes:

Offer type

Billing account changes

Subscription transfer/migration events • Azure Support can confirm:

Who/what changed the quota

Whether a backend adjustment occurred

The audit history for the affected SKU families • To prevent future DR failures:

Pre-allocate DR region quota for full failover capacity

Add quota validation to the DR runbook

Configure quota usage alerts (for example 70% and 90% thresholds) In short: quotas do not self-reduce. Either a subscription-level change or a backend action caused the reduction, and Azure Support can verify the exact audit trail.
Manoj Kumar Boyini 19,430 Reputation points Microsoft External Staff Moderator

2026-08-05T03:15:14.2433333+00:00

Hi @Joshua Schmidlkofer

I kindly request you to please share the details requested in the private message for further investigation.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-08-13T06:10:57.0066667+00:00

Hi @Joshua Schmidlkofer ,

Just checking in to see if the information provided earlier was helpful. Please let us know if you need any additional details or assistance, and we’ll gladly continue supporting you.

Answer 1

Hello Joshua Schmidlkofer,

Greetings! Thanks for raising this question in the Q&A forum.

The root cause here is that two different things are being compared as if they were the same thing. Azure vCore quota is a provisioning limit tied to your subscription and region. It caps how many vCores you are allowed to deploy or scale up to in that region, and it is only checked at the moment you create, scale, or fail over a server. CPU usage percentage is a runtime performance metric that measures how hard the vCores you already provisioned are working. A server can run at 100% CPU utilization indefinitely without ever touching the quota, because the quota was already consumed the moment the vCores were provisioned, regardless of how busy they are afterward. That is why there were no alerts: there was no quota violation in progress, only a capacity ceiling that only becomes visible when you try to provision new or additional compute, such as during your DR failover.

Check what quota actually blocked you

Go to Azure Portal, then Subscriptions, then your subscription, then Usage + quotas, and filter for Azure Database for PostgreSQL Flexible Server (or Microsoft.DBforPostgreSQL) in the region where DR was attempted. This shows current usage against the regional vCore limit for that resource type. This is almost certainly what blocked the DR scale operation, not your production server's live CPU load.

Understand why the numbers look alarming

Comparing production CPU utilization percentage against a vCore quota number is comparing a performance metric to a provisioning ceiling, so the 50 percent and 600 percent figures describe two unrelated things. Your servers were not silently violating anything. The regional quota simply was not sized to allow you to provision the additional vCores your DR process needed, most likely in the paired or secondary region rather than your primary.

Request a quota increase before your next DR test

From the same Usage + quotas page, select the subscription and region, and submit a quota increase request for the vCore SKU family your production and dev servers use. Approval is typically fast for standard SKU families but should be requested well ahead of any DR exercise, since quota increases are not instantaneous.

Set up the alerting that actually applies here

Quota consumption itself has no built-in alert in Azure Monitor because it is not a metered runtime signal, it is a static ceiling checked at request time. What you can and should alert on is CPU percentage via Azure Monitor metric alerts on each server, which will warn you before sustained high CPU becomes a performance problem, separate from the DR quota issue entirely. You can also query the Microsoft.DBforPostgreSQL usages via the Azure Resource Manager REST API or CLI on a schedule and push the result into Datadog as a custom metric, since quota is not natively exposed as a first party Azure Monitor metric that the Datadog integration can pull.

Right-size vCore allocation going forward

Since your dev server is running at 6 times its provisioned vCore count in practice, treat that as a signal the dev tier itself is undersized for its actual workload, independent of the quota conversation. Consider moving it to a larger SKU or a different compute tier so its provisioned vCores better match real usage.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix

Joshua Schmidlkofer 0 Reputation points

2026-07-10T14:37:42.9566667+00:00

I failed to communicate properly in my initial message. I was too close to the problem, and I had too many hours of trying to determine how to open a ticket with the accompanying frustration.

This is not about server utilization, this is about the Azure PostgreSQL vCore provider Quotas, and nothing else.

When I failed to spawn a new instance for a DR database, I traced the Bad Request to a Quota denial. When I opened the Quota dashboard, the quota for standardedsv4family showed 100% usage, when I tried to request additional quota, the actual usage was 600% higher than the quota - literally 6x the current quota. For another standardesv3family it was only 2x the current quota. You are probably familiar with the time it takes to extend quotas. We literally spammed the quota-increase requests until it worked, while trying to get Support on the phone. Ultimately, we were able to address the immediate problem, but that has left us with a separate question: How or When did the quotas get lowered?

No one in my team lowered or adjusted quotas. They simply dropped between the last time we extended quotas and the 8th.
Smaran Thoomu 335 Reputation points Microsoft External Staff Moderator

2026-07-15T01:41:11.79+00:00

Hi Joshua Schmidlkofer,

Thank you for clarifying your scenario. I understand that your concern is specifically about the vCore quota values appearing to have been reduced, rather than CPU utilization or quota enforcement during provisioning.

Based on what you've shared, Azure PostgreSQL quotas aren't expected to decrease on their own under normal circumstances. Since no changes were made from your side, it's understandable that you'd want to know what caused the reduction.

Unfortunately, from the Q&A forum we don't have access to subscription-level quota history or backend records to verify whether a quota change occurred or what may have triggered it.

If this behavior persists or you need confirmation of whether the quota values were modified, the recommended path would be to work with Azure Support, as they have access to the backend information needed to validate quota history.

In the meantime, if you're able to share (without including any sensitive information):

The Azure region

The affected quota family (for example, standardedsv4family)

Whether this was observed only in the DR region or also in the primary region

we'll be happy to review the scenario further and see if there's any additional guidance we can provide from the Q&A side.

Thank you for taking the time to explain the issue more clearly.