Let's break down why you're hitting this error and how to fix it—this is a common gotcha with ARM templates for alert rules, especially when using automation scripts as a starting point.

The Root Cause #

First, look at the alert name in your error: CPU default-app-name-plan-ins-westeurope-default-environment. The inclusion of "plan" here is a big clue—your alert rule is likely targeting an App Service Plan (Microsoft.Web/serverfarms) instead of the actual Web App (Microsoft.Web/sites) you intended. Even if you meant to target the Web App, incorrect resource ID references or missing dependencies can also cause the target resource to not be found during deployment.

Step-by-Step Fixes #

1. Correct the Target Resource ID

Ensure your alert rule's configuration points directly to your Web App using the resourceId function. Avoid manual string concatenation for resource IDs—this is where most mismatches happen.

In your alert rule's properties, verify the targetResourceId (or in older API versions, the dataSource.resourceUri for metric alerts) uses the correct resource type:

"properties": {
    "targetResourceId": "[resourceId('Microsoft.Web/sites', variables('webAppName'))]",
    // ... rest of your condition/actions
}

Double-check that variables('webAppName') matches the exact name of your deployed Web App resource. If your automation script pulled in the Plan's ID instead of the Web App's, this is where you'll need to swap the resource type from Microsoft.Web/serverfarms to Microsoft.Web/sites.

2. Add a Dependency on the Web App

ARM deployments run in parallel by default, so your alert rule might be trying to create before the Web App exists. Add a dependsOn block to ensure the Web App is fully deployed first:

{
    "type": "microsoft.insights/alertrules",
    "location": "[variables('location')]",
    "apiVersion": "2016-03-01",
    "name": "[concat('CPU ', variables('webAppName'))]",
    "dependsOn": [
        // Reference the Web App resource to enforce deployment order
        "[resourceId('Microsoft.Web/sites', variables('webAppName'))]"
    ],
    "properties": {
        // ... alert configuration
    }
}

3. Verify Alert Name and Variable References

Your alert name uses concat('CPU ', variables('insightComp...'))—make sure the insightComp variable is correctly pulling the Web App's identifier, not the Plan's. If the variable includes "plan" in its value, that's why your alert name has it, and it's a sign your target resource is misaligned.

4. Validate API Version Compatibility

While 2016-03-01 is a valid API version for alertrules, if you're still having issues, try using a newer version like 2020-01-01 (note: parameter names might change slightly, so cross-reference the Azure ARM template schema for updates).

Example Corrected Snippet #

Here's how your alert rule configuration should look with the fixes applied:

{
    "type": "microsoft.insights/alertrules",
    "location": "[variables('location')]",
    "apiVersion": "2016-03-01",
    "name": "[concat('CPU ', variables('webAppName'))]",
    "dependsOn": [
        "[resourceId('Microsoft.Web/sites', variables('webAppName'))]"
    ],
    "properties": {
        "description": "High CPU usage alert for Web App",
        "isEnabled": true,
        "targetResourceId": "[resourceId('Microsoft.Web/sites', variables('webAppName'))]",
        "condition": {
            "odata.type": "Microsoft.Azure.Management.Insights.Models.ThresholdRuleCondition",
            "dataSource": {
                "odata.type": "Microsoft.Azure.Management.Insights.Models.RuleMetricDataSource",
                "resourceUri": "[resourceId('Microsoft.Web/sites', variables('webAppName'))]",
                "metricName": "CpuPercentage"
            },
            "operator": "GreaterThan",
            "threshold": 80,
            "windowSize": "PT5M"
        },
        "actions": [
            {
                "odata.type": "Microsoft.Azure.Management.Insights.Models.RuleEmailAction",
                "sendToServiceOwners": true
            }
        ]
    }
}

After applying these changes, redeploy your ARM template—this should resolve the "no target resource" error by ensuring the alert rule points to the correct Web App and waits for it to exist before deploying.

内容的提问来源于stack exchange，提问作者Putnik