Why does Application Insights Diagnostic Setting Recreate Itself Automatically After Deletion?

Please check the following:

Whether an Azure Policy is configured to automatically deploy diagnostic settings.

Whether any ARM, Bicep, or Terraform deployments are recreating the diagnostic setting.

Whether any automation (Deployment Stacks, Automation Accounts, or CI/CD pipelines) is reapplying the resource configuration.

@Jose Benjamin Solis Nolasco

Policy: No Azure Policy assignments were found targeting diagnostic settings on this subscription or resource group. *I tried to share a screenshot, but second image will not upload.

ARM, Bicep, Terraform: No ARM, Bicep, or Terraform deployments are managing or recreating any resource, nor this diagnostic setting. Nor anything other resource.

Automation, Deployment Stacks, Automation Accounts, CI/CD pipelines: No automation accounts, Deployment Stacks, or CI/CD pipelines manage underlying Azure resource configuration. We do use Azure DevOps but is used solely for application code deployments to App Service and does not manage or configure app insights or diagnostic settings. Nor any other resource except for webapp code deployment.

Hello Daniel-4204

Thank you for posting your query on Microsoft Q&A platform and detailed explanation of your issue.

Your root-cause diagnosis for the duplicate telemetry is exactly right, and this is a documented known issue. However, the recreation you are now seeing is not platform behavior tied to the workspace-based migration. Azure Monitor / Application Insights does not automatically create or restore diagnostic settings. The "Events" diagnostic setting is not a default, hidden, or "self-present" resource on workspace-based Application Insights.

The Diagnostic Settings blade is intentionally empty on a workspace-based AI resource because native ingestion already writes everything to the linked Log Analytics workspace. Sending diagnostic settings to that same workspace is the exact scenario Microsoft calls out as causing duplicates.

1. Confirming what you already fixed:

For workspace-based Application Insights, the diagnostic-settings destination cannot be the same Log Analytics workspace the AI resource is linked to. Application Insights performs cross-resource stitching for end-to-end transactions and app maps, so if the same telemetry lands in the linked workspace via both the native pipeline and a diagnostic setting, every row is duplicated (same operation_Id, same span id, same duration, different itemId) This is exactly what you observed.

Deleting the diagnostic setting is the correct and only remediation and there is no supported way to tell Application Insights to ignore the duplicate ingestion path.

2. Why the setting keeps coming back and please look into below to know what is really happening:

A 1–3 hour recreation cadence, with no create event visible in the standard Activity Log export, is the classic signature of Azure Policy with a DeployIfNotExists (DINE) effect. There are Microsoft built-in policies and initiatives that specifically target Microsoft.Insights/components (Application Insights) and deploy a diagnostic setting to a Log Analytics workspace if one is not present.

Common examples:

• "Enable logging by category group for Application Insights (microsoft.insights/components) to Log Analytics" (built-in DINE)
• "Deploy Diagnostic Settings for Application Insights to Log Analytics Workspace" (built-in / initiative form)
• Any custom DINE policy in your management-group hierarchy that enforces diagnostic settings on microsoft.insights/components

DeployIfNotExists works exactly this way, after a configurable delay, the Azure Policy engine evaluates the resource, sees that the required diagnostic setting is missing (because you just deleted it), and the policy assignment's managed identity deploys it back through a nested ARM template. This is why:

• The caller on the create event is the policy assignment's managed identity, not a user and Activity Log CSV exports filtered by administrative operations frequently miss it.
• The Get-AzLog / az monitor activity-log list commands return nothing for you, those default to the Administrative category. Policy-initiated deployments show under the Policy category and as PolicyDeployment_* deployments in the resource group.

Reference:

• Azure Policy deployIfNotExists effect

Other (less common) sources with the same fingerprint:

• An IaC pipeline (Bicep/ARM/Terraform/Azure DevOps release) that runs on a schedule and re-applies a module still declaring the Events diagnostic setting.
• Azure Automation runbook / Logic App / Function timer that enforces monitoring configuration.
• A third-party CSPM/governance tool (Defender for Cloud recommendations enforced through DINE, Azure Landing Zones "Deploy Diagnostic Settings" initiative, etc.).

3. To identify the source please perform below steps in order:

1. Check Azure Policy compliance for the resource:

Azure portal → Policy → Compliance → set scope to the subscription (or the management group above it) → filter by resource: your Application Insights component.

Any assignment listed as Non-compliant against your AI resource that has effect deployIfNotExists and targets Microsoft.Insights/diagnosticSettings is your culprit.

1. Look at deployments in the resource group: Portal → the AI resource's resource group → Deployments. Policy remediations appear as PolicyDeployment_<guid> or names starting with the initiative/definition name. The initiated by column will show the managed identity of the policy assignment.
2. Filter Activity Log by Policy category (not Administrative):

Portal → the AI resource → Activity log → Category = Policy → look for Microsoft.Authorization/policies/deployIfNotExists/action and the subsequent Microsoft.Insights/diagnosticSettings/write.

This is why your CSV export didn't show it — the CSV was scoped to Administrative operations initiated by your account.

1. KQL against AzureActivity in the same workspace:

AzureActivity
| where TimeGenerated > ago(3d)
| where ResourceProvider == "MICROSOFT.INSIGHTS"
| where OperationNameValue endswith "diagnosticSettings/write"
| project TimeGenerated, Caller, CallerIpAddress, OperationNameValue, ActivityStatusValue, Authorization_d, Claims_d

The Caller will be a GUID (the policy assignment's managed identity object ID). You can resolve it under Microsoft Entra ID → Enterprise applications (filter by Application type = Managed Identities).

4. Please have a look into below supported remediation options:

Once you identify the assignment, choose one:

• Preferred — exempt the resource:

Create an Azure Policy exemption on the Application Insights resource (or its RG) for that specific assignment.

Category = Waiver with a justification like "Workspace-based Application Insights, native ingestion already routes telemetry to the linked LAW, diagnostic setting would duplicate ingestion per Microsoft guidance." This is the cleanest and most auditable option.

• Change the policy parameter's destination workspace to a different Log Analytics workspace than the one the AI resource is linked to. That satisfies the policy without producing duplicates (though you'll pay ingestion twice, so exemption is usually better).
• Narrow the assignment scope so it does not cover this resource / RG / subscription.
• If it turns out to be an IaC pipeline, remove the Microsoft.Insights/diagnosticSettings block for this component from the template/module.

Identify the DINE policy assignment (or IaC job) using the steps above, then exempt your workspace-based Application Insights resource(s) from it, or change the assignment's target workspace parameter to a different workspace. Deletion alone will always be undone by the enforcing mechanism.

Please let me know if the Policy → Compliance blade shows a non-compliant assignment against the resource.

Thanks,

Suchitra

@Suchitra Suregaunkar

Hi Suchitra,

Thank you for the detailed response. We have worked through all three investigation areas and can confirm the following:

Policy at subscription scope: A full policy compliance export confirms every policy in the environment uses AuditIfNotExists, Audit, or Disabled effects only. No DeployIfNotExists or Modify policies exist at this scope.

Policy at management group / tenant root level: Our subscription sits directly under the Tenant Root Group with no intermediate management groups. There are three policies assigned at that level, all Microsoft-managed platform policies for MFA enforcement and region access restriction. None target diagnostic settings or Microsoft.Insights/components.

AzureActivity KQL: The query you provided returned no results for diagnosticSettings/write operations against MICROSOFT.INSIGHTS in the last 3 days when run against our Log Analytics workspace.

ARM, Bicep, Terraform, automation: No IaC tooling manages this resource. No PolicyDeployment_* deployments were found at either the resource group or subscription level. No automation accounts, runbooks, or pipelines manage diagnostic settings on this resource.

Hello Daniel-4204

Thanks for sharing the details. I will check on this and keep you posted updates further.

Thanks,

Suchitra.