Forum Discussion
Region-access support requests for PostgreSQL Flexible Server are stuck in an AI triage loop
As an Azure MVP, I want to flag a real gap I just hit firsthand.
I opened a support ticket (Issue type: Service and subscription limits (quotas), Quota type: Region access) because a subscription of ours couldn't provision Azure Database for PostgreSQL Flexible Server in East US — az postgres flexible-server list-skus --location eastus returns "Provisioning is restricted in this region... open a support request with Issue type of 'Service and subscription limits'", exactly as documented.
Over 9 days, I got three AI-generated responses (case #2608260040010469), all repeating the exact same generic instructions I had already followed and explicitly confirmed I'd followed — twice. No human engineer was ever assigned (confirmed via the Support API: supportEngineer: {} the entire time). The case was even auto-flagged for closure citing "no response," despite an active reply from me on record before that message was sent.
This isn't a one-off complaint about response speed — it's a structural problem: region-access requests for this service appear to route through an automation loop that can't recognize "I already did what you're asking" and doesn't have a reliable escalation path to a human, even after an explicit "I'm still having an issue" signal.
Has anyone else hit this on region-access requests specifically? And is there a known way to get these routed to an actual engineer instead of restarting the same script every 24-48h?
2 Replies
Thanks Jamony — to close the loop: Microsoft.DBforPostgreSQL is registered, and the original ticket (#2608260040010469) already included the exact region (East US), subscription ID, SKU, vCore count, and the CLI error text. I also explicitly requested manual review and flagged the auto-closure risk in two follow-up replies before the case tried to close itself. At this point I don't think there's anything left for me to add on the customer side — this needs someone from the actual PostgreSQL Flexible Server support/product team to pick it up. If you know anyone who could take a direct look, I'd really appreciate a nudge.
You have already followed the documented region-access route, but the request is cycling through automated replies without an assigned engineer. The CLI message means provisioning is restricted for that subscription and region; it is not something an ARM template, role change, or CLI setting can bypass. First confirm Microsoft.DBforPostgreSQL is registered and that the request was opened under Azure Database for PostgreSQL Flexible Server, naming East US, the required vCore count, SKU, availability-zone needs, subscription ID, and CLI error. Add those facts and the nine-day timeline to the case, then explicitly request manual review and protection from automatic closure. Avoid opening duplicate requests, because that can split the history. There is no documented customer-side command that grants regional access. If deployment cannot wait, test an approved region and update the architecture for latency and residency. Only Microsoft support can approve capacity access or explain why the request is stalled.
