Azure Deployment Takes 70 Minutes to Fail with Obscure Error

👁 Image

Mike-E-angelo 631 Reputation points

{
 "code": "ResourceDeploymentFailure",
 "target": "/subscriptions/<subscription>/resourceGroups/<group>/providers/Microsoft.Cache/redisEnterprise/<name>",
 "message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'."
}

👁 User's image

Thank you for any assistance to track down what is going on here.

👁 Image

Mike-E-angelo 631 Reputation points

Hi @Anonymous thank you for your reply but that is a lot of information you are asking for as I have already provided the correlation ID which should give you all the information you need. Can you please confirm that Redis instances are able to be deployed without error? Thank you for your continued assistance.
👁 Image

Mike-E-angelo 631 Reputation points

I have tried another deployment and instead of it gracefully with a comprehensive error message like you see in every Microsoft product but Azure, it fails with the most obscure and useless message you can think of, as if your team is creatively finding ways to confuse the user. Why are you emitting failure errors that give no indication of why the operation failed? I hope you can understand the concern.
👁 Image

Mike-E-angelo 631 Reputation points

I have tried another deployment and instead of it gracefully with a comprehensive error message like you see in every Microsoft product but Azure, it fails with the most obscure and useless message you can think of, as if your team is creatively finding ways to confuse the user. Why are you emitting failure errors that give no indication of why the operation failed? I hope you can understand the concern.

Answer recommended by moderator

👁 Image

Mike-E-angelo 631 Reputation points

So I was able to get a deployment successfully made when switching the region to eastus2. There was ZERO mention of anything region-specific in the error. What you see above is the error that is presented to the user and it is astounding to me that this is considered acceptable by every person working at Azure.

👁 Image

Mike-E-angelo 631 Reputation points

Ironically I was using eastus because eastus2 was throwing errors regarding databases at one point. This whole system is truly Jenga, especially when very little information is presented to the user to help them solve the problem they are experiencing.
👁 Image

Anonymous

Hi @Mike-E-angelo

The error means the connection didn’t have a valid database context or the Entra identity isn’t fully registered inside that database. You don’t need to add pgaadauth as an extension manually—it’s built into the service. The right approach is to enable Entra authentication at the server and then create the identity as a principal in the target database.

Make sure you’re connecting with the correct FQDN (not IP), using SSL, and explicitly specifying the database name.

After that, confirm the identity exists in that database and grant the roles you need. Without that, even if the token looks fine, the database won’t recognize you.

If you’re on Flexible Server, this is the standard flow. If it’s Cosmos DB for PostgreSQL, the steps differ slightly.
👁 Image

Mike-E-angelo 631 Reputation points

Hi @Anonymous thank you for your reply.

The error means the connection didn’t have a valid database context or the Entra identity isn’t fully registered inside that database. You don’t need to add pgaadauth as an extension manually—it’s built into the service. The right approach is to enable Entra authentication at the server and then create the identity as a principal in the target database.

How can you be so sure about this? Exactly zero of this is relayed in the error message presented to me. Additionally, as I was able to deploy to eastus2 without issue, this also seems to imply this was a different issue altogether than you are suggesting.
👁 Image

Anonymous

Hi Mike,

Thank you for the detailed feedback and for your patience here – I completely understand how frustrating it is to wait ~70 minutes only to see a generic “deployment failed” error with no actionable details.

Based on the behavior you described and the fact that the same Redis Enterprise deployment succeeds in eastus2 but consistently fails in eastus, this strongly suggests a region-specific platform/capacity issue in eastus rather than a problem with your ARM/Bicep template or parameters.

the deployment should fail quickly with a clear reason such as “SKU unavailable or capacity exhausted in this region” instead of a generic ResourceDeploymentFailure after a long timeout. I’ve flagged this feedback to the team so they can review both the error message and the timeout behavior for such cases.
👁 Image

Anonymous

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications
👁 Image

Mike-E-angelo 631 Reputation points

Hi @Anonymous thank you for the kind words but what exactly do you hope that is helpful? I managed to "fix" the issue on my own by using another region, and your comments seem to suggest that you are going to flag this with a team somewhere to review the terrible user experience this has saddled upon your customer. Regions may play a role in this issue, but it is still very unclear exactly what occurred here. Can you please confirm that my correlation ID and all the information requested of me is being used to determine root cause? Thank you for your continued assistance.
👁 Image

Anonymous

Yes, your correlation ID and the details you shared are being used. I’ve passed them to the product team so they can pull the exact backend logs for your failed deployment in eastus and confirm root cause.as soon as the team confirms what happened, I’ll come back and update this thread with the final explanation, not just the workaround.
👁 Image

Mike-E-angelo 631 Reputation points

Thank you, Swapnesh. That is good to hear. Looking forward to hearing what has occurred here.
👁 Image

Mike-E-angelo 631 Reputation points

Hi @Anonymous why are you asking me for a correlation id when I have already provided it in the chat? Additionally you are asking me for the time of the incident and shouldn't the correlation Id already tell you this? What is the correlation ID correlating if not the time of the incident? I hope you can understand the concern. Additionally, why are you asking for this information nearly two weeks after the incident? You gave the very distinct impression that this was already being actively investigated. I hope you can understand the concern you are placing upon customers who report active and obvious defects in your software.
👁 Image

Anonymous

Hi @Mike-E-angelo

Unfortunately, the backend team attempted to validate the deployment logs for the provided correlation ID but did not find any logs. They searched for deployments from your subscription and discovered that the AMR cache was already created on 2025-11-15 at 12:31:53 UTC. They are now inquiring what's pending from this case.

Are you seeking the root cause of previous cache deployment failures attempted before 11/15?
👁 Image

Mike-E-angelo 631 Reputation points

Hi @Anonymous thank you for your investigation.

Unfortunately, the backend team attempted to validate the deployment logs for the provided correlation ID but did not find any logs

What? Why are you providing correlation IDs to your users when they do not seem to correlate with anything? I hope you can understand the concern.

They searched for deployments from your subscription and discovered that the AMR cache was already created on 2025-11-15 at 12:31:53 UTC.

Confirm that this is eastus2 and NOT eastus where the error occurred.

Are you seeking the root cause of previous cache deployment failures attempted before 11/15?

If that is the correlation ID of the failure I reported nearly two weeks ago, then yes? Why is it so difficult and takes so long to report obvious and flagrant errors occurring in your system? It is compounded by the painful consideration that such an obvious exception should be reported to you and your teams automatically in the first place. Does a deployment that takes over 70 minutes to complete with an obscure failure seem "normal" to you? What am I missing here? Again, I hope you can understand the rather obvious and apparent concern here.
👁 Image

Anonymous

Hi @Mike-E-angelo

Thank you for your patience. We have thoroughly reviewed the correlation ID and confirmed that no related logs exist for the earlier failure. The cache was successfully created in eastus2 on 2025‑11‑15, and there are no active issues at this time.

We understand your concern and will escalate this internally to improve error reporting and correlation tracking. While we cannot retrieve additional details for the previous attempt, please be assured that your feedback will bring improvements to prevent such gaps in the future.
👁 Image

Mike-E-angelo 631 Reputation points

Wow, so if I understand correctly @Anonymous , you essentially made me wait for half a month under the pretense that you were actively investigating this issue, when in fact you were not at all. In doing so, you allowed the logs to expire while they were still meaningful and valuable to the investigation? It also seems you and your team repeatedly misunderstood the situation, as I clearly stated that the WORKAROUND (as denoted by the "recommended answer" here -- one I cannot accept as such btw, adding to the perceived low quality experience from start to finish of your services) was to deploy to eastus2. This has been known for several weeks now, and you are repeating this in your findings as if this is a new development.

There may not be an "active failure at this time", but there is certain defective software lurking in your system. Defects that should be reported to you automatically and not weeks after the fact by your slow and clearly overburdened support team.

I hope you understand the concern. Please put yourself in my situation. Would you honestly feel this to be a pleasant user experience for your product? Thank you for your consideration.
👁 Image

Anonymous

Hi @Mike-E-angelo

We sincerely apologize for the frustration and inconvenience this situation has caused. Your concerns are completely valid, and we deeply regret that the investigation did not meet your expectations.

We acknowledge the gap in log retention and communication, and we are taking immediate steps to improve error reporting, proactive alerts, and support responsiveness to prevent this from happening again.
👁 Image

Mike-E-angelo 631 Reputation points

Thank you, @Anonymous for your understanding and reply, it is appreciated. To be sure, are you saying that when a 70-minute deployment fails without a meaningful message to your user, you will be getting a report of this immediately in your system and will not require the user to report it to you?

4 additional answers

👁 Image

Mike-E-angelo 631 Reputation points

Hi @Anonymous why are you asking me for a correlation id when I have already provided it in the chat? Additionally you are asking me for the time of the incident and shouldn't the correlation Id already tell you this? What is the correlation ID correlating if not the time of the incident? I hope you can understand the concern. Additionally, why are you asking for this information nearly two weeks after the incident? You gave the very distinct impression that this was already being actively investigated. I hope you can understand the concern you are placing upon customers who report active and obvious defects in your software.

0 comments No comments

Sign in to comment
👁 Image

Mike-E-angelo 631 Reputation points

I have tried another deployment and instead of it gracefully with a comprehensive error message like you see in every Microsoft product but Azure, it fails with the most obscure and useless message you can think of, as if your team is creatively finding ways to confuse the user. Why are you emitting failure errors that give no indication of why the operation failed? I hope you can understand the concern.

0 comments No comments

Sign in to comment
👁 Image

Anonymous

Hi Mike-E-angelo ,

Welcome to the Microsoft Q&A and thank you for posting your questions here.
Could you please share the details requested in the private message for further investigation.

0 comments No comments

Sign in to comment
AI answer
The error message you are encountering indicates that the deployment of the Azure Cache for Redis resource has failed, reaching a terminal provisioning state of 'Failed'. This can happen for a variety of reasons, including issues with resource availability, configuration errors, or permission problems.

To troubleshoot this issue, you can follow these steps:

Check Deployment Operations: Use the Azure portal to view the deployment operations associated with your deployment. This will provide more detailed error messages that can help identify the specific cause of the failure. You can do this by navigating to the resource group in the Azure portal, selecting Deployments, and then reviewing the error details for the failed deployment.

Review Resource Limits: Ensure that you are not exceeding any quotas or limits for your Azure subscription, particularly those related to the Azure Cache for Redis service.

Validate Configuration: Double-check the configuration settings for your Redis resource. Ensure that all required parameters are correctly specified and that they conform to Azure's naming and configuration guidelines.

Permissions: Make sure that the account or service principal you are using has sufficient permissions to create and manage the resources in the specified resource group.

Retry Deployment: Sometimes, transient issues can cause deployments to fail. You might want to retry the deployment after addressing any potential issues.

If the problem persists, consider reaching out to Azure support with the correlation ID and tracking ID you provided, as they can help investigate further.

References:

Troubleshoot common Azure deployment errors

Find error codes
AI-generated content may be incorrect. Read our transparency notes for more information.

URL: https://learn.microsoft.com/en-us/answers/questions/5622379/azure-deployment-takes-70-minutes-to-fail-with-obs?page=1

⇱ Azure Deployment Takes 70 Minutes to Fail with Obscure Error - Microsoft Q&A

Azure Deployment Takes 70 Minutes to Fail with Obscure Error

4 additional answers

Your answer