Diagnostic logs in Logic Apps should be enabled

What does the recommendation "Diagnostic logs in Logic Apps should be enabled" check?

Flags any Consumption logic app (Microsoft.Logic/workflows) that has no diagnostic setting routing the 'WorkflowRuntime' log category to a Log Analytics workspace, storage account or event hub. The underlying built-in policy, 'Resource logs in Logic Apps should be enabled', runs as AuditIfNotExists, so it verifies only that a setting exists and is enabled, not that you actually query the data, retain it for a useful period or capture every category. It does not inspect what the workflow does, whether the destination is reachable, or whether anyone reads the logs. The control also does not cover the Standard single-tenant runtime, which emits App Service style host logs and Application Insights traces rather than the Consumption WorkflowRuntime category, so a Standard logic app is out of scope here and needs its own logging review.

Why does "Diagnostic logs in Logic Apps should be enabled" matter?

Trigger, run and action events are the only durable record of what a workflow actually did with your data. Without a diagnostic setting those events live only in the built-in run history, which expires on a fixed window and cannot be searched, joined or alerted on across apps. After a security incident, a leaked secret in a connector, or a silent integration failure that quietly drops orders, you are then left with no trail of which payloads moved, which connector fired or who invoked the trigger. Investigation stalls, root-cause work drags on for days, and you may be unable to evidence to an auditor or customer what was and was not exposed. Exporting WorkflowRuntime to Log Analytics keeps an independent, queryable audit trail outside the resource itself, which is exactly what you need when the resource is the thing under suspicion.

How do I fix "Diagnostic logs in Logic Apps should be enabled"?

1. Create or reuse a Log Analytics workspace, then add a diagnostic setting on the logic app that enables the 'WorkflowRuntime' log category (the portal Quick Fix also enables 'AllMetrics').
2. From the CLI: az monitor diagnostic-settings create --name la-diag --resource <logic-app-resource-id> --workspace <workspace-resource-id> --logs '[{"category":"WorkflowRuntime","enabled":true}]'.
3. Bake it into your Bicep so new workflows ship compliant: declare a Microsoft.Insights/diagnosticSettings resource scoped to the workflow with logs[].categoryGroup set to allLogs (or category WorkflowRuntime) and workspaceId pointing at the shared workspace.

# Turn on the security-relevant App Service logs and send them to a workspace.
WS=$(az monitor log-analytics workspace show \
  -g central-logging -n estate-logs --query id -o tsv)

for id in $(az webapp list --query "[].id" -o tsv); do
  has=$(az monitor diagnostic-settings list --resource "$id" \
        --query "length(value)" -o tsv)
  if [ "$has" = "0" ]; then
    az monitor diagnostic-settings create \
      --name to-log-analytics \
      --resource "$id" \
      --workspace "$WS" \
      --logs '[{"category":"AppServiceHTTPLogs","enabled":true},
               {"category":"AppServiceAuditLogs","enabled":true},
               {"category":"AppServiceConsoleLogs","enabled":true}]'
    echo "$(basename "$id"): diagnostic logging enabled to estate-logs"
  fi
done

# Ratchet it shut: built-in policy adds the setting to any new App Service.
az policy assignment create \
  --name deploy-appservice-diag \
  --policy 0c6cd767-1a1d-484b-a897-68e398c03aeb \
  --location uksouth \
  --mi-system-assigned \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"