An Azure service that provides protection for web apps.
Use this read-only triage flow to identify the cause of failed create, update, or delete operations on Azure Application Gateway.
- Identify the last failed operation.
- In Azure portal, go to Application Gateway > Activity log.
- Filter for:
- Resource = the Application Gateway
- Status = Failed
- Time range = when the issue occurred
- Open the most recent failed event. If there are multiple failures, start with the first failed operation because later failures can be cascading.
- Record:
- Operation name
- Error code
- Error message
- statusMessage in Properties > JSON
- If the failure came from an ARM deployment, retrieve the deployment error details with
az deployment operation group list.
- Check the provisioning state and interpret it.
- Succeeded: the issue may already be resolved or transient. If the symptom persists, continue deeper validation.
- Failed: inspect the error details and continue based on the error code.
- Updating for more than 30 minutes: wait up to one hour. If it is still updating after that, file an Azure support request.
- Branch by the error code.
- AuthorizationFailed: the deploying identity is missing required permissions.
- For inherited role assignments, include
--include-inheritedwhen checking permissions. Without it, inherited Owner or Contributor assignments can appear missing and lead to misdiagnosis. - Use the
{OBJECT_ID}from theAuthorizationFailedmessage to verify the exact identity. - Required permissions depend on the operation:
- Create/update:
Microsoft.Network/applicationGateways/write,Microsoft.Network/virtualNetworks/subnets/join/action - Delete:
Microsoft.Network/applicationGateways/delete - Read:
Microsoft.Network/applicationGateways/read - Public IP assignment:
Microsoft.Network/publicIPAddresses/join/action - Key Vault certificates:
Microsoft.KeyVault/vaults/secrets/read,Microsoft.ManagedIdentity/userAssignedIdentities/assign/action - Managed identity use:
Microsoft.ManagedIdentity/userAssignedIdentities/read
- Create/update:
- For inherited role assignments, include
- ScopeLocked or OperationNotAllowed with a lock reference: a resource lock is blocking the operation.
- Check for
CanNotDeleteorReadOnlylocks on the resource, resource group, subscription, or dependent resources such as public IP, VNet, or NSG. -
CanNotDeleteblocks deletion and can block some updates that require re-creation. -
ReadOnlyblocks all write operations, including deployment, scaling, updates, and deletion.
- Check for
- SubnetTooSmall or InvalidSubnet: validate the Application Gateway subnet configuration.
- ApplicationGatewaySubnetInboundTrafficBlockedByNetworkSecurityGroup: an NSG on the Application Gateway subnet is blocking required
GatewayManagerinbound management traffic on ports65200–65535for v2. - ApplicationGatewaySubnetUserDefinedRouteNotAllowed: a UDR on the Application Gateway subnet has a
0.0.0.0/0route whose next hop is notInternet.- Application Gateway v2 requires the default route next hop to be the internet.
- Routing through an NVA or VPN gateway can cause deployment and health probe failures.
- ResourceProviderNotRegistered: register or verify registration of the
Microsoft.Networkresource provider.
- AuthorizationFailed: the deploying identity is missing required permissions.
- Validate network dependencies if backend reachability is involved.
- Check NSGs on both the Application Gateway subnet and backend subnet.
- Check UDRs to ensure traffic is not redirected away from the backend.
- Check custom DNS on the VNet. If backend pool members use FQDNs, confirm the configured DNS server resolves them correctly.
- If backend access is blocked by NSG, UDR, or DNS, probe failures can occur and lead to 502 behavior.
- If Key Vault certificates are involved, validate the certificate path.
For
ApplicationGatewayKeyVaultSecretExceptionor “Problem occurred while accessing and validating KeyVault Secrets associated with Application Gateway”, verify:- The user-assigned managed identity has
Getpermission on Key Vault secrets. - If using service endpoints, the Application Gateway VNet and subnet are explicitly allowed in Key Vault firewall and virtual network settings.
- If using private endpoints, the
privatelink.vaultcore.azure.netprivate DNS zone is linked to the VNet containing the gateway. - The private DNS zone contains a valid A record for the Key Vault private endpoint.
- The managed identity still exists.
- The Key Vault and certificate object are not deleted or soft-deleted.
- The referenced secret and certificate are in Enabled state.
- The user-assigned managed identity has
- Check for orphaned configuration references if updates or scaling fail unexpectedly.
- Look for path map rules that reference backend pools not present in
backendAddressPools. - Look for HTTP settings references missing from
backendHttpSettingsCollection. - Look for routing rules referencing deleted listeners.
- Look for redirect configurations targeting deleted listeners.
- If any referenced resource ID returns
404, the gateway still contains a deleted external dependency reference.
- Look for path map rules that reference backend pools not present in
- Check autoscale configuration if the gateway is healthy but scaling or cost is unexpected.
- A gateway can show
provisioningState: "Succeeded"and still scale beyond expectations if no maximum autoscale capacity is set. - Review the
skutier andautoscaleConfigurationminimum and maximum bounds.
- A gateway can show
- Escalate when the error is non-diagnostic.
- If the failed event shows Internal Server Error, open a support request and provide:
- the failed operation timestamp
- the
correlationIdfrom the failed activity log event JSON
- If the failed event shows Internal Server Error, open a support request and provide:
This sequence gives an end-to-end way to classify the failure first, then validate the most common blockers: permissions, locks, subnet/NSG/UDR issues, provider registration, Key Vault access, deleted dependencies, and autoscale configuration.
References: