APIM Consumption custom domain update rolls back with UpdateApiServiceFailed after about 23 minutes

Tymur Popov 0 Reputation points
2026-10-18T16:50:03.7766667+00:00

I cannot bind a custom Gateway hostname to an Azure API Management Consumption instance. The update is accepted, runs for about 23 minutes, and then rolls back with UpdateApiServiceFailed. The service subsequently reports Succeeded but contains only its built-in azure-api.net hostname.

Environment and checks:

  • Region: Sweden Central; Consumption tier; no VNet integration.
  • The custom CNAME pointed directly to the APIM default hostname and was verified using public DNS before the update.
  • Custom certificate: Let's Encrypt, RSA 2048, valid SAN entries and more than two months remaining validity.
  • The PFX includes the private key, intermediates and ISRG Root X1; it uses triple-DES encryption. The chain and expected leaf were verified.
  • A previous Key Vault-backed binding also failed. New managed certificate creation previously returned ManagedCertificateConfigurationTemporaryDisabled.
  • The API hostname was previously used by App Service and is currently also bound to Azure Container Apps for rollback. Existing Container Apps asuid and separate APIM apimuid TXT records were preserved.
  • ARM API version: 2024-05-01.

The only terminal error is UpdateApiServiceFailed / Unable to Update API service at this time. It refers to resource-group deployment logs, but there is no corresponding failed APIM ARM deployment with actionable details. Correlation IDs and exact timestamps are available privately to a Microsoft engineer.

The standard APIM endpoints work: liveness and rejection of unknown routes/methods pass; CSRF cookie flags, credentialed CORS, preflight, unauthenticated protected-route rejection and Public API readiness also pass. DNS has been restored to Container Apps and direct-origin HTTPS readiness succeeds.

This Microsoft-resolved case appears similar, although we have not confirmed the same cause:

https://learn.microsoft.com/en-sg/answers/questions/5857543/apim-custom-domain-registration-fails

Could a Microsoft engineer check whether a stale App Service/domain ownership registration is preventing this hostname update? Is an additional or corrected asuid value required, and what is the supported migration sequence while retaining a rollback path to Container Apps? What diagnostic can expose the actual backend provisioning error?

Our Basic support plan blocks creation of a private technical support ticket. Please advise a secure channel for sharing resource identifiers and correlation IDs; none are included in this public post.

Azure API Management
Azure API Management

An Azure service that provides a hybrid, multi-cloud management platform for APIs.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Alex Burlachenko 26,275 Reputation points MVP Volunteer Moderator
    2026-10-26T08:58:48.5766667+00:00

    Hi Tymur Popov & thx for join me at Q&A platform,

    ur findings point more toward APIM hostname provisioning or domain ownership validation than an API configuration issue. The fact that both PFX and Key Vault bindings failed makes a certificate-specific problem less likely, although it doesn't completely rule one out. The case you linked is particularly relevant. Microsoft confirmed that the domain ownership TXT record contained an incorrect value, and the issue was resolved after the backend team supplied the required asuid value. Asuid and apimuid serve different validation purposes. I wouldn't replace your existing Container Apps ownership record or invent another asuid value based on that case.

    I'd verify the authoritative DNS responses and check whether the hostname is still registered against the previous App Service resource. The existing Container Apps binding is also worth mentioning to engineering, but neither proves a stale registration.

    For migration, keep Container Apps available as your rollback target. If APIM requires the CNAME to point directly to its default hostname during validation, plan that DNS change carefully and restore the original target if provisioning fails. Testing with a separate hostname first would reduce production risk.

    The generic UpdateApiServiceFailed message and missing ARM deployment details suggest that the actionable error may only be available in APIM's internal provisioning logs.

    Your correlation IDs and UTC timestamps are exactly what Microsoft engineering needs to investigate the hostname registration and ownership validation.

    Basic Support doesn't provide the normal technical investigation route, and u know Q&A moderators cannot directly inspect backend records or guarantee a private escalation. A Microsoft employee would need to arrange an appropriate secure channel or support escalation.

    I wouldn't keep repeating 23-minute deployments until the ownership records have been checked.

    rgds,

    Alex

    p.s. if my answer is help - pls mark it as an answer

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.