Share via

Check if any monitoring metrics/alerts already exist for App Service (Web App / Worker)

Selvam Sekar 100 Reputation points
2026-05-18T16:15:02.1533333+00:00

Hi Team,

We are trying to understand the current monitoring setup for our Azure App Services and wanted to check if there is a way to identify whether any monitoring configurations have already been created by other teams.

Specifically, we are looking for:

  • Azure App Service (Web Apps)
  • Worker instances

We would like to know:

Is there a way to list all existing monitoring configurations for these resources, such as:

  • Metrics-based alerts
    • Diagnostic settings
      • Application Insights configurations
      Can we centrally query (via REST API, Azure CLI, or Resource Graph) to identify: 
      - Which App Services already have alerts configured

   - What metrics are being monitored

      - Any existing alert rules tied to these resources

      Is there any recommended best practice to audit or inventory monitoring coverage across multiple subscriptions?

Our goal is to avoid duplicate configurations and understand what monitoring is already in place before onboarding additional alerts or dashboards.

Any guidance, sample queries, or references would be helpful.

Thanks in advance

Azure Monitor
Azure Monitor

An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Suchitra Suregaunkar 14,420 Reputation points Microsoft External Staff Moderator
    2026-05-18T19:02:33.63+00:00

    Hello Selvam Sekar

    Thank you for reaching out. Understanding your existing monitoring setup before onboarding new alerts or dashboards is absolutely the right approach to avoid duplication.

    Here's how you can centrally discover what's already configured for your Azure App Services (Web Apps and Workers/App Service Plans):

    1. List All Existing Alert Rules for App Services

    The most efficient way to query alert rules across multiple subscriptions is Azure Resource Graph Explorer (available directly in the Azure portal). Run this KQL query:

    resources
| where type == "microsoft.insights/metricalerts"
| mv-expand scope = properties.scopes
| where tolower(tostring(scope)) contains "microsoft.web/sites"
    or tolower(tostring(scope)) contains "microsoft.web/serverfarms"
| mv-expand criteria = properties.criteria.allOf
| project alertName = name,
          resourceGroup,
          subscriptionId,
          severity = tostring(properties.severity),
          enabled = tostring(properties.enabled),
          metricName = tostring(criteria.metricName),
          operator = tostring(criteria.operator),
          threshold = tostring(criteria.threshold),
          targetResource = tostring(scope)

    This returns all metric-based alert rules targeting your Web Apps (microsoft.web/sites) and App Service Plans / Workers (microsoft.web/serverfarms), along with the specific metrics being monitored, thresholds, and severity.

    You can also view recently fired alerts using:

    alertsmanagementresources
| where properties.essentials.startDateTime > ago(12h)
| where tostring(properties.essentials.targetResourceType) in~ ("microsoft.web/sites", "microsoft.web/serverfarms")
| project name, severity = tostring(properties.essentials.severity),
          alertState = tostring(properties.essentials.alertState),
          targetResource = tostring(properties.essentials.targetResource),
          startDateTime = todatetime(properties.essentials.startDateTime)

    Official doc: Azure Resource Graph sample queries for Azure Monitor

    Using Azure CLI:

    az monitor metrics alert list --resource-group <resource-group-name> --output table

    Official doc: az monitor metrics alert

    Using REST API:

    GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Insights/metricAlerts?api-version=2018-03-01

    Filter the response where properties.scopes contains your App Service resource IDs.

    2. Check Diagnostic Settings

    Azure CLI:

    # For a specific Web App
az monitor diagnostic-settings list \
  --resource "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{app-name}"

# For an App Service Plan (Worker)
az monitor diagnostic-settings list \
  --resource "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Web/serverfarms/{plan-name}"

    Official doc: az monitor diagnostic-settings

    REST API:

    GET https://management.azure.com/{resourceUri}/providers/Microsoft.Insights/diagnosticSettings?api-version=2021-05-01-preview

    Official doc: Diagnostic settings in Azure Monitor

    3. Check Application Insights Configuration

    To verify whether Application Insights is already linked to a Web App:

    Azure CLI:

    az webapp config appsettings list \
  --name <app-name> \
  --resource-group <rg-name> \
  --query "[?name=='APPINSIGHTS_INSTRUMENTATIONKEY' || name=='APPLICATIONINSIGHTS_CONNECTION_STRING']"

    If these app settings exist and have values, Application Insights is configured for that Web App.

    You can also list all Application Insights resources across your subscriptions using Resource Graph:

    resources
| where type == "microsoft.insights/components"
| project name, resourceGroup, subscriptionId,
          instrumentationKey = tostring(properties.InstrumentationKey),
          retentionDays = tostring(properties.RetentionInDays)

    Official doc: Enable Application Insights for Azure App Service

    4. Best Practice: Audit Monitoring Coverage Across Subscriptions

    Azure Monitor – Monitoring Coverage (Preview): Azure Monitor now includes a centralized Monitoring Coverage experience to identify gaps in your observability posture. Navigate to Azure Monitor → Settings → Monitoring Coverage (Preview) in the portal. It highlights which resources have basic vs. enhanced monitoring enabled and lets you apply recommendations at scale.

    Official doc: Monitoring coverage in Azure Monitor (preview)

    Azure Policy for Governance at Scale: Use built-in Azure Policies (e.g., "Deploy diagnostic settings for App Service to Log Analytics workspace") to enforce monitoring configurations automatically. You can assign these as initiatives across management groups or subscriptions, and create remediation tasks to apply them to existing resources.

    Official doc: Create diagnostic settings at scale using built-in Azure policies

    Hope this helps! If you have any follow-up questions, feel free to ask.

    Thanks,

    Suchitra.

    Was this answer helpful?

    1 person found this answer helpful.

  2. AI answer

    2026-05-18T16:15:18.5266667+00:00

    For App Service (web apps and workers), monitoring data is exposed through Azure Monitor. Existing monitoring and alerting can be discovered centrally by querying Azure Monitor resources (metrics, logs, alerts) across subscriptions.

    Key points from the provided information:

    1. App Service emits standard platform metrics under the Microsoft.Web/sites and related namespaces. These are automatically available in Azure Monitor and can be queried and used for metric alerts.
      • Web apps: Microsoft.Web/sites
      • App Service plans: Microsoft.Web/serverfarms
      • Slots and App Service Environment variants have their own metric namespaces.
      • Only Basic/Standard/Premium App Service Plans expose plan-level metrics.
    2. For security and operational monitoring of App Service, recommended components are:
      • Diagnostic logging (App Service diagnostics) for application errors, web server logs, failed request traces, and detailed errors.
      • Integration with Azure Monitor for collecting and analyzing logs and metrics, and for creating metric alerts.
      • Application Insights for application performance and usage telemetry.
      • Health checks for instance-level health monitoring.
    3. Azure Monitor alerts and their metadata can be queried centrally using Azure Resource Graph. The sample queries in the context show how to query alertsmanagementresources across subscriptions and join with resources to enrich with tags:
      • The sample Resource Graph query projects alert properties such as:
        • alertId, name, monitorCondition, severity, monitorService, alertState, targetResourceType, targetResource, subscriptionId, startDateTime, lastModifiedDateTime, and dimensions.
      • It then joins with the resources table to bring in targetResourceTags.
    4. For auditing monitoring coverage and existing alerts across multiple subscriptions, the recommended pattern is:
      • Use Azure Resource Graph queries against alertsmanagementresources to list alerts, filter by targetResourceType (for example, Microsoft.Web/sites), and group or filter by subscription, severity, or tags.
      • Use the resources table in the same query to correlate alerts with App Service resources and their tags.
      • Optionally, use Alert processing rules to suppress or route alerts without changing the underlying alert definitions.
    5. For Activity Log–based alerts on resource creation, the context clarifies:
      • Activity log alerts support inclusion filters but not exclusions by user.
      • To do more advanced filtering (for example, exclude certain users), Log Analytics–based alerts are required, using KQL queries over Activity Logs.
      • Alternatively, Alert processing rules can be used to suppress actions/notifications for certain alert instances based on alert payload (Alert Context filter), while still allowing the alert to be generated.

    Putting this together for the requested scenarios:

    • To discover which App Services already have metric or log alerts configured and what they monitor, use Azure Resource Graph queries over alertsmanagementresources, filtering on targetResourceType = Microsoft.Web/sites and related types, and projecting dimensions and other properties to see the monitored metrics and conditions.
    • To understand diagnostic logging and Application Insights coverage, use Azure Monitor integration and App Service diagnostics configuration per app, and correlate via Resource Graph resources and tags. (The context does not provide a specific query for diagnostic settings or Application Insights links, only the recommendation to configure them.)
    • As a best practice for auditing monitoring coverage across subscriptions:
      • Standardize on Azure Monitor (metrics, logs, alerts) for App Service.
      • Use Resource Graph queries similar to the provided samples to inventory alerts and correlate them with resources and tags.
      • Use tags on App Service resources to indicate monitoring ownership, criticality, and whether monitoring has been validated.
      • Use Alert processing rules to avoid duplicate or noisy notifications when multiple teams manage alerts.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.