Flex Consumption (West Europe): one worker repeatedly loses DNS for ~60 s (EAI_AGAIN), host lease renewal fails

Hi Daniel V & thx for join me at Q&A platform,

The per-instance pattern is the most interesting part here. You're seeing getaddrinfo EAI_AGAIN across unrelated Azure services, while other instances of the same Function App continue working normally. And you've reproduced similar behavior in another subscription in West Europe.

That makes a shared application configuration issue less likely and puts worker-level DNS resolution or outbound networking fairly high on the list. It doesn't prove a platform defect yet, but this deserves more investigation than the usual advice to restart the app or increase retry counts.

I couldn't confirm a published Azure Functions incident covering your specific October 18–19 timestamps in West Europe. The February incident is useful historical context, but I wouldn't assume the same root cause without backend evidence.

One distinction regarding the host lease errors: 409 LeaseIdMismatchWithLeaseOperation means the host no longer owns the lease it's trying to renew. It can follow a delayed renewal or host transition, but it isn't independently proof of DNS failure. The fact that it coincides with your dependency failures is relevant, tho I'd also check for CPU saturation, event-loop delays, and broader outbound connectivity problems during those 60 seconds.

For VNet integration, Flex Consumption supports it, but there's no documented guarantee that enabling it fixes intermittent platform DNS failures. Using Azure-provided DNS through a VNet doesn't necessarily give you an independent resolver. A custom DNS configuration might change the resolution path, but it also introduces new networking dependencies. I'd test that in a separate app before treating VNet integration as a production workaround.

Regarding recycling the affected worker, an application restart isn't equivalent to replacing the underlying platform worker. The fact that the same cloud_RoleInstance appears afterward doesn't necessarily mean the same host process survived, either. As far as the supported customer-facing controls go, there isn't a documented way to target and evict one specific Flex Consumption worker. I wouldn't rely on repeated restarts, redeployments, or configuration changes to force placement elsewhere.

I'd correlate the failures by cloud_RoleInstance in Application Insights and compare exceptions, dependency failures, and host traces within the same UTC window. For example:

exceptions
| where timestamp between (
    datetime(2026-10-19T11:20:00Z) ..
    datetime(2026-10-19T11:50:00Z)
)
| summarize Failures=count()
    by bin(timestamp, 1m), cloud_RoleInstance, type, outerMessage
| order by timestamp asc

It would also help to log a lightweight DNS lookup alongside an outbound TCP connection test during an episode. That can distinguish a resolver-specific failure from a more general worker networking problem. Avoid using a direct IP address as a production workaround for Azure SQL or HTTPS services because hostname-based TLS validation still matters.

For immediate mitigation, three retries spaced two seconds apart clearly won't cover the observed outage. For idempotent operations, consider exponential backoff with jitter over a longer bounded window, while keeping the total duration within your HTTP request timeout. For synchronous requests, returning a temporary failure and letting an upstream caller retry may be safer than holding connections open for a minute. This reduces impact but doesn't address the underlying problem.

Given the repeated incidents, precise timestamps, and cross-subscription reproduction, I'd raise this as a suspected Azure Functions Flex Consumption platform networking issue rather than an ordinary application DNS troubleshooting question.

Even without a paid technical support plan, you can check Azure Service Health and the available support routes for a suspected service incident. A Microsoft Q&A thread cannot guarantee a private engineering investigation or worker replacement, so I'd avoid posting resource IDs or detailed telemetry publicly unless a Microsoft employee provides an appropriate secure channel.

The most valuable evidence for the Functions team would be the affected Function App resource IDs, exact UTC windows, cloud_RoleInstance values, host instance identifiers if available, and correlated DNS, dependency, and lease-renewal failures. That should help them investigate whether the affected executions share an unhealthy platform networking component.

At this stage, a platform-side investigation is justified, but neither VNet integration nor restarting the app can be presented as a confirmed fix.

rgds,

Alex

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