Send runtime logs to Azure Monitor Logs

Send your web app's standard output (stdout) and standard error (stderr) to a customer-owned Log Analytics workspace. This is separate from build and deployment logs in the Portal. Configure the destination through Azure Resource Manager (ARM) using properties.telemetry.azureMonitorLogs.

Prerequisites

• An existing Builder web app and permission to update it through the ARM API.
• Azure CLI installed and signed in with az login, and PowerShell for the command examples below.
• Permission to create the monitoring resources and assign an ingestion role on the data collection rule (DCR).

Export setup

Export requires an environment with runtime log export enabled and an app with a managed identity that can ingest to your data collection rule.

The Portal and Builder CLI do not provide a runtime-log export setup form or command. Monitoring resources have their own charges, retention, and access settings. Keep credentials, sensitive variable values, and customer data out of stdout/stderr.

Configure runtime log export

1. Create a Log Analytics workspace and a custom Log Analytics table

   • In Azure Portal, create or select a Log Analytics workspace.
   • Use your app's region for the monitoring resources to keep exported logs there.
   • Create a custom table for App Service Builder runtime logs.
   • Include these columns:

   Column	Type
   TimeGenerated	datetime
   LogContent	string
   LogStream	string
   SandboxId	string
   Region	string
   ContainerName	string
   AppId	string
   DeploymentId	string

2. Create a Data Collection Endpoint (DCE) and a Data Collection Rule

   • Create a Data Collection Endpoint in the same Azure region as the monitoring resources.
   • Add a custom stream whose schema matches the table columns.
   • Add the Log Analytics workspace as the destination.
   • Route the custom stream to the custom table.
   • Associate the Data Collection Endpoint with the rule.
   • Record:
     • The DCR immutable ID, beginning with dcr-.
     • The custom stream name, beginning with Custom-.

3. Configure the app's managed identity

   Log export requires the app's system-assigned identity to be enabled. Ingestion uses either that identity or an attached user-assigned identity.

   To use the system-assigned identity, record its principal ID.

   To use a user-assigned identity, attach it to the app and record its complete ARM resource ID.

4. Grant ingestion permission

   • On the Data Collection Rule, assign the following role to the identity that will send logs:

   Monitoring Metrics Publisher

   • Scope the assignment to the DCR resource.

5. Update the app to configure runtime logging

   Wait for any in-progress deployment to finish. The examples below show only the logging settings. Preserve the app's other writable configuration, including its identity, when preparing the complete PUT body; do not copy read-only response fields. See the ARM API reference for field and update rules.

   To use the app's system-assigned identity, omit identityResourceId:

   {
     "location": "<builder-app-location>",
     "properties": {
       "telemetry": {
         "azureMonitorLogs": {
           "dceEndpoint": "https://<dce-name>.<region>-1.ingest.monitor.azure.com",
           "dcrImmutableId": "dcr-<immutable-id>",
           "streamName": "Custom-<stream-name>"
         }
       }
     }
   }

   To use an attached user-assigned identity, include its resource ID:

   {
     "location": "<builder-app-location>",
     "properties": {
       "telemetry": {
         "azureMonitorLogs": {
           "dceEndpoint": "https://<dce-name>.<region>-1.ingest.monitor.azure.com",
           "dcrImmutableId": "dcr-<immutable-id>",
           "streamName": "Custom-<stream-name>",
           "identityResourceId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>"
         }
       }
     }
   }

   Replace the placeholders with your app and monitoring resource values. Use the DCE's actual logs-ingestion endpoint and the DCR's immutable ID, not its ARM resource ID. Save the complete request body as telemetry.json, then run:

   $subscriptionId = "<builder-app-subscription-id>"
   $resourceGroup = "<builder-app-resource-group>"
   $appName = "<builder-app-name>"
   $apiVersion = "2026-09-01-preview"
   $bodyFile = ".\telemetry.json"
   
   $resourceId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Web/builderApps/$appName"
   
   az rest `
     --method put `
     --url "https://management.azure.com${resourceId}?api-version=$apiVersion" `
     --headers "Content-Type=application/json" `
     --body "@$bodyFile"

6. Verify the configuration

   az rest `
     --method get `
     --url "https://management.azure.com${resourceId}?api-version=$apiVersion" `
     --query "properties.{telemetry:telemetry.azureMonitorLogs,deploymentId:runtime.activeDeploymentId,url:runtime.url}" `
     --output json

7. Generate traffic and query the logs

   • Have your app write a harmless identifiable message to stdout or stderr. Send a request to the url returned above that triggers that message.
   • Replace <CustomTableName> with your custom table's base name and <active-deployment-id> with the deploymentId returned above.
   • Query the custom table:

   <CustomTableName>_CL
   | where TimeGenerated > ago(30m)
   | where DeploymentId == "<active-deployment-id>"
   | project
       TimeGenerated,
       LogStream,
       LogContent,
       ContainerName,
       SandboxId,
       Region,
       AppId,
       DeploymentId
   | order by TimeGenerated desc

   Confirm that a new record contains your test message and the current deployment ID. AppId is also available in the results if you need to filter by app. An accepted settings update does not prove that logs have arrived.

Update or disable export

The destination is app-owned configuration, not a setting frozen into each app version. For an active runtime, a destination update does not rebuild source or create a version. If no web runtime is active, the saved destination is used on the next deployment. Omitting telemetry preserves the destination; sending "telemetry": {} disables export. Preserve the app's other writable fields when sending PUT.

Troubleshoot missing logs

If the workspace remains empty, check the DCR stream/table mapping, the selected identity's ingestion permission, and the destination values. Confirm that the app emitted a new stdout/stderr message; an HTTP request alone does not guarantee a log entry. If the service reports that telemetry is not enabled in the environment, contact your preview contact rather than repeatedly submitting the same update.

Related content

Logging and monitoring explains build and deployment diagnostics. The ARM API reference defines runtime-log destination fields and update semantics.