Azure Function App 'Runtime Unreachable' traced to missing VNet integration and private DNS

A Linux Azure Function App that showed 'Runtime Unreachable' in the Azure Portal before any code was deployed turned out to be a networking problem, not an application one. According to a walkthrough published on dev.to, the fix came in two parts: regional VNet integration to give the app outbound reach into the virtual network, and a separate private endpoint with Private DNS configuration for a second storage account used by the application.

The failure

The author was provisioning a new Linux Function App on the Elastic Premium EP1 plan in an environment that already had a shared VNet holding private resources. Immediately after creation, the Portal could not display the Functions runtime version, and ZIP deployments failed without producing usable application-level logs. Because no Python code existed yet, suspects such as a broken function file, wrong dependencies, or a malformed package were ruled out from the start. When the host cannot initialise before your code runs, the article argues, the first place to look is the infrastructure the host depends on, above all storage.

Private storage was the blocker

The storage account bound to this Function App was protected by network restrictions and reachable only over private networking. Function Apps already running in the environment worked fine because they had been integrated with the VNet; the new app had not. That single mismatch left the app without a route to storage it required.

As the dev.to post notes, Azure Functions rely on their configured storage account for core host operations, and Premium plans commonly use Azure Files for function content and deployment, wired through settings such as AzureWebJobsStorage and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. If that account is private, the app reaches it through the VNet or not at all.

Integration is outbound; private endpoints are addresses

The walkthrough stresses a distinction that trips up newcomers. Regional VNet integration is an outbound capability: it lets the Function App make calls into the VNet, including to resources exposed via private endpoints. It does not make the app itself privately reachable from that network. A private endpoint, by contrast, gives an Azure resource a private IP address inside the VNet. Troubleshooting differs depending on which half is broken.

The first fix

The author mirrored the configuration of a working Function App. In the Portal, under Function App, then Networking, then Virtual Network Integration, they attached the app to the same VNet and a dedicated integration subnet. That subnet must be delegated to Microsoft.Web/serverFarms. Microsoft documents /28 as the minimum size for Elastic Premium integration and recommends a larger subnet for Linux Premium workloads, since every running instance consumes an IP address and scaling can temporarily require more. One rule the article calls out explicitly: do not reuse the private-endpoint subnet as the integration subnet, because the two serve different purposes, and Microsoft's own samples keep them separate. After a restart and a few minutes for the networking changes to settle, the runtime came back.

The second failure was DNS

With the host healthy, a simple health-check function reported that Key Vault was reachable but blob storage was failing with the error: Failed to resolve 'contentarchive.blob.core.windows.net', no address associated with hostname. The author highlights why this mattered: it was a name-resolution error, not AuthorizationPermissionMismatch or a 403, so the app had a path but no resolvable address. This storage account was a separate business-content store the application used for processed documents, distinct from the app's own storage. Per the walkthrough, the resolution was creating a dedicated private endpoint for that account together with the matching Private DNS configuration, which the author credits with restoring connectivity.

Why it matters

'Runtime Unreachable' is one of the most opaque failure modes in Azure Functions, and it commonly appears exactly where this story did: locked-down environments where storage is private. The case offers two transferable lessons. First, when the host fails before any code has shipped, suspect platform dependencies such as storage connectivity and DNS rather than the application. Second, VNet integration and private endpoints solve different halves of the problem: integration provides outbound reach, while private endpoints plus Private DNS zones provide resolvable private addresses. Getting the subnet delegation, sizing, and separation right the first time turns what was a blind debugging session into a repeatable checklist.