topic Re: X_NHC_CONTROL_PLANE_UNREACHABLE in Administration & Architecture

X_NHC_CONTROL_PLANE_UNREACHABLE

taglud_dbw — Wed, 12 Aug 2026 20:51:18 GMT

I have this issue

[details] X_NHC_CONTROL_PLANE_UNREACHABLE: Instance failed network health check before bootstrapping with fatal error: X_NHC_CONTROL_PLANE_UNREACHABLE 2 failed component(s): control_plane internet Retryable: true Based on the failure results: List(entity: "**region**-c2.azuredatabricks.net" outcome: "unreachable" duration_sec: 281.2346 message: "curl: (28) Connection timed out after 10000 milliseconds" last_error_code: 28 , entity: "www.databricks.com" outcome: "unreachable" duration_sec: 225.03764 message: "curl: (28) Failed to connect to www.databricks.com port 443 after 7603 ms: Connection timed out" last_error_code: 28 )(OnDemand)

i did all the network check recommanded by AI

No custom route tables

No custom DNS

No failed Azure deployments

Correct NSG rules
what could be the issue in your opinion ? should i recreate the resource ?

Re: X_NHC_CONTROL_PLANE_UNREACHABLE

szymon_dybczak — Wed, 12 Aug 2026 21:42:54 GMT

Hi @taglud_dbw ,

The first thing I would check: does the subnet actually have outbound Internet access?

This is especially important for a recently created VNet/workspace. Azure changed its default behavior: for new VNets, subnets now default to being private, so VMs do not automatically receive default outbound Internet connectivity. An explicit outbound mechanism such as a NAT Gateway is required.

Microsoft specifically calls this out for Azure Databricks: new VNet-injected workspaces require explicit outbound connectivity, and NAT Gateway is the recommended approach.

"After March 31, 2026, new VNets require explicit outbound connectivity methods. See secure cluster connectivity."

Re: X_NHC_CONTROL_PLANE_UNREACHABLE

balajij8 — Thu, 13 Aug 2026 05:26:52 GMT

Recreating the workspace or VNet won't solve X_NHC_CONTROL_PLANE_UNREACHABLE as the error indicates that the underlying instances are failing outbound health checks over HTTPS during the node bootstrap sequence. Issue mostly stems from a subtle egress path restriction or subnet-level misconfiguration.

Check for an upstream Firewall or Network Virtual Appliance. Even if you haven't assigned custom route tables directly, verify whether forced tunneling or an upstream firewall is intercepting internet traffic via an inherited 0.0.0.0/0 route and silently dropping outbound HTTPS traffic to the control plane.
Check the subnet delegation and Service Endpoints. Verify that both the public and private subnets are correctly delegated to Microsoft.Databricks/workspaces. Check under Subnets → Service Endpoints to ensure Microsoft.AzureDatabricks is enabled where required.
If you are using Azure Private Link, verify that private endpoint DNS resolution is running as expected. If its a standard deployment, ensure outbound internet egress isn't being blocked at a broader network boundary.
Review NSG outbound rules to ensure you are utilizing the AzureDatabricks Service Tag rather than relying on individual static IP addresses, which can lead to connection timeouts if the underlying control plane infrastructure relies on dynamic ranges.