---
cuppy_hub: azure
cuppy_path: reference/load-balancer/errors.md
cuppy_section: docs
cuppy_doc: 04Q3-XJY7
cuppy_doc_uuid: c041cb10-835c-46bd-a7f4-5ae5dddf7a88
cuppy_permalink: https://cuppy.io/azure/d/04Q3-XJY7
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/azure/docs/reference/load-balancer/errors
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: fb5e21073280de6363cfa856aa2bb77528222630282f09047c74f4d5f34ed67e
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Load Balancer errors

**Basic Load Balancer and Basic public IPs retired on September 30, 2025**: use Standard (or StandardV2 public IPs where a resource needs them). A **Standard** load balancer and Standard public IP are **closed to inbound traffic until an NSG allows it**: with no NSG on the backend subnet or NIC, nothing arrives. Add an NSG with an explicit allow rule for the frontend port.

## Deployment errors

| Code | Cause → fix |
|---|---|
| `DifferentSkuLoadBalancersAndPublicIPAddressNotAllowed` | Load balancer and public IP SKUs differ: make them match (Standard) |
| `DifferentSkuLoadBalancerAndPublicIPAddressNotAllowedInVMSS` | A scale set without a SKU or Standard instance IPs picked Basic: specify Standard |
| `MaxAvailabilitySetsInLoadBalancerReached` | More than 150 availability sets in the backend pool; standalone VMs each count as one |
| `RulesOfSameLoadBalancerTypeUseSameBackendPortProtocolAndIPConfig` / `…AndVmssIPConfig` | Two rules on the same backend port and protocol for the same scale set: change one |
| `AnotherInternalLoadBalancerExists` / `VMScaleSetCannotUseMultipleLoadBalancersOfSameType` | At most one internal and one public load balancer per backend set |
| `CannotUseInactiveHealthProbe` | A scale set's health probe isn't used by any rule |
| `LoadBalancerWithoutFrontendIPCantHaveChildResources` | Add a frontend IP configuration before rules, probes or pools |
| `LoadBalancerRuleCountLimitReachedForNic` | A backend NIC can be in at most 300 rules |
| `LoadBalancerInUseByVirtualMachineScaleSet` | Delete or detach the scale set named in the error first |
| `SpecifiedAllocatedOutboundPortsForOutboundRule…` | Outbound rule port settings: `reference/networking/outbound-connectivity.md` |
| `ResourceDeploymentFailure` with the load balancer in a **Failed** state | Re-send the resource unchanged (Microsoft's steps use a PUT then GET in Resource Explorer) until `provisioningState` is `Succeeded` |

## Health probes mark backends down

| Finding | Fix |
|---|---|
| Backend pool empty, or NICs of deleted or deallocated VMs | Fix pool membership |
| Probe port isn't the port the app listens on, or the app stopped | Match the port; restart the service |
| HTTP/HTTPS probe path returns anything but **200** (403, 404, 500 and redirects all fail, immediately) | Point the probe at an anonymous path returning 200 |
| An NSG or guest firewall blocks **`AzureLoadBalancer`** / **168.63.129.16** on the probe port | Allow it; the default rule `AllowAzureLoadBalancerInBound` (65001) does unless a higher-priority deny overrides it |
| Slow responses, or an aggressive probe (interval ≤ 5 s and one probe) | Make the endpoint faster, or relax the interval and count |

Check with the **Health Probe Status** metric and the load balancer's health event logs; from a VM in the VNet, call the probe path yourself. Connection troubleshoot reports this as `DIPProbeDown` (`guides/networking/diagnose-connectivity.md`).


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 107 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/azure/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->