How to fix Error creating App Service Plan: WebHostingPlanNotFound in Terraform

TerraformINTERMEDIATEMEDIUMUpdated Dec 31, 2025ยท 104 views

The "WebHostingPlanNotFound" error occurs when Terraform attempts to create an Azure App Service or Function App but cannot find or properly reference the associated App Service Plan (ServerFarm). This error typically stems from resource dependency issues, mismatched resource groups, or naming conflicts.

Quick fix

Fixes WebHostingPlanNotFound

resource "azurerm_service_plan" "example" {
  name                = "example-plan"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  os_type             = "Linux"
  sku_name            = "B1"
}
  1. Verify the App Service Plan resource exists in your configuration
  2. Correct the service plan ID reference in your app resource
  3. Add explicit dependency if using data source references
  4. Ensure all resources are in the same resource group
terraform โ€” error
resource "azurerm_service_plan" "example" {
name = "example-plan"
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location
os_type = "Linux"
sku_name = "B1"
}
Error creating App Service Plan: WebHostingPlanNotFound

What this error means

The WebHostingPlanNotFound error is returned by Azure when a resource (like an App Service or Function App) references an App Service Plan that Azure cannot locate. This can happen for several reasons: 1. The App Service Plan (also called ServerFarm or Web Hosting Plan) does not exist in the specified resource group or subscription. 2. Azure Resource Manager is trying to create dependent resources (the App Service) before the App Service Plan is fully created, due to missing explicit dependencies. 3. The reference to the plan ID is incorrect or malformed. 4. The plan exists in a different resource group or region than the app attempting to use it.

Typical symptoms

  • Terraform apply fails with "WebHostingPlanNotFound" error
  • Error appears when creating App Service or Function App resources
  • The error occurs even though you believe the App Service Plan exists in Azure
  • Applying the same configuration twice: first fails, second succeeds
  • App Service Plan exists in Azure portal but Terraform cannot find it

Common causes

  1. Missing explicit dependency (depends_on) between App Service Plan and the dependent resource
  2. Incorrect or incomplete App Service Plan ID reference in the app configuration
  3. App Service Plan and the dependent resource are in different resource groups
  4. App Service Plan is still being created when the dependent resource tries to reference it
  5. Resource group name is misspelled or does not match between resources
  6. Using incorrect attribute name (e.g., app_service_plan_id vs service_plan_id depending on provider version)

How to fix "Error creating App Service Plan: WebHostingPlanNotFound"

1Verify the App Service Plan resource exists in your configuration

First, ensure your Terraform configuration explicitly creates the App Service Plan resource. Check for a resource block like:

hcl
resource "azurerm_service_plan" "example" {
  name                = "example-plan"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  os_type             = "Linux"
  sku_name            = "B1"
}

If you are using the deprecated azurerm_app_service_plan, update to azurerm_service_plan for AzureRM provider 3.0+.

2Correct the service plan ID reference in your app resource

Ensure your App Service or Function App resource correctly references the plan ID. For modern AzureRM provider:

hcl
resource "azurerm_linux_web_app" "example" {
  name                = "example-app"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_service_plan.example.location
  service_plan_id     = azurerm_service_plan.example.id
}

Note the attribute name is service_plan_id (not app_service_plan_id). Check your provider documentation for the correct attribute.

3Add explicit dependency if using data source references

If you are referencing an existing App Service Plan (not creating it in the same configuration), use the depends_on meta-argument:

hcl
data "azurerm_service_plan" "existing" {
  name                = "my-existing-plan"
  resource_group_name = "my-resource-group"
}

resource "azurerm_linux_web_app" "example" {
  name                = "example-app"
  resource_group_name = azurerm_resource_group.example.name
  service_plan_id     = data.azurerm_service_plan.existing.id

  depends_on = [data.azurerm_service_plan.existing]
}
4Ensure all resources are in the same resource group

The App Service Plan and the app resource must be in the same resource group. Verify:

hcl
# Both resources use the same resource group
resource "azurerm_service_plan" "example" {
  resource_group_name = azurerm_resource_group.example.name
  # ...
}

resource "azurerm_linux_web_app" "example" {
  resource_group_name = azurerm_resource_group.example.name
  service_plan_id     = azurerm_service_plan.example.id
  # ...
}

Do not create the plan in one resource group and the app in another.

5Check provider version compatibility

If migrating from older configurations, ensure your AzureRM provider version is consistent. Update your provider block:

hcl
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

Run terraform init to update providers and lock files.

6Import existing App Service Plans if not creating them

If the App Service Plan already exists in Azure and you need to manage it with Terraform, import it:

bash
terraform import azurerm_service_plan.example /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Web/serverfarms/{plan-name}

Then add the corresponding resource block to your configuration. This prevents Terraform from trying to create a duplicate plan.

Advanced notes

Dependency Resolution: Terraform creates resources in parallel by default. If you have multiple apps using the same plan, all will try to reference it simultaneously. Ensure the plan is created first with explicit ordering.

Deprecated Resource Names: The azurerm_app_service_plan resource was deprecated in favor of azurerm_service_plan. If upgrading an old configuration, use terraform state mv to migrate the resource in state.

Linux vs Windows Plans: Ensure the plan's OS type (os_type = "Linux" or os_type = "Windows") matches the app type (azurerm_linux_web_app vs azurerm_windows_web_app).

Regional Quotas: Some regions have quota limits on the number of App Service Plans per subscription. If you get this error after creating many plans, try a different region.

Shared Plans: If a plan exists in one resource group and you want to use it from another (cross-resource-group deployment), you must reference it via data source with the full resource ID path.

Frequently asked questions

What does "WebHostingPlanNotFound" mean?
The WebHostingPlanNotFound error is returned by Azure when a resource (like an App Service or Function App) references an App Service Plan that Azure cannot locate. This can happen for several reasons: 1. The App Service Plan (also called ServerFarm or Web Hosting Plan) does not exist in the specified resource group or subscription.
How do I fix "WebHostingPlanNotFound"?
The "WebHostingPlanNotFound" error occurs when Terraform attempts to create an Azure App Service or Function App but cannot find or properly reference the associated App Service Plan (ServerFarm). This error typically stems from resource dependency issues, mismatched resource groups, or naming conflicts.
What causes "WebHostingPlanNotFound"?
Missing explicit dependency (depends_on) between App Service Plan and the dependent resource Incorrect or incomplete App Service Plan ID reference in the app configuration App Service Plan and the dependent resource are in different resource groups
Is the "WebHostingPlanNotFound" error serious?
It is a medium-severity error โ€” more of a blocker than a risk. The steps above resolve it.

Official resources & further reading