How to Monitor Azure Application Gateway Request Latency and Backend Health: Step-by-Step Guide 2026

Azure Application Gateway sits at the edge of your infrastructure where every latency spike, backend failure, or 4xx error here affects every downstream service. Without proper monitoring, a slow database query or an unhealthy backend pool can quietly degrade user experience for hours before anyone notices.

This guide walks through monitoring Application Gateway request latency and backend health using Azure Monitor metrics, diagnostic logs, health probes, and alerting. By the end, you will know how to track total request time, backend response time, unhealthy host counts, and configure alerts that catch issues before they cascade.

Prerequisites

Before starting, ensure you have:

• An active Azure subscription with an Application Gateway deployed
• Contributor or Owner role on the Application Gateway resource
• Azure Monitor enabled for the subscription
• Access to Azure Portal and Azure CLI (optional but recommended for automation)
• Diagnostic settings enabled or permission to configure them
• A Log Analytics workspace (optional but recommended for deeper log analysis)
• Basic familiarity with Azure Monitor metrics and alerts

Step 1: Understand Key Application Gateway Metrics

Azure Application Gateway exposes multiple metrics that measure request latency and backend health. The most critical ones are:

Application Gateway Total Time: Time from when Application Gateway receives the first byte of an HTTP request to when the response send operation finishes. This includes Application Gateway processing time, network travel time, and backend server response time.

Backend Connect Time: Time spent establishing a connection with a backend server. Includes network latency and the backend server’s TCP stack time. For TLS connections, this includes handshake time.

Backend First Byte Response Time: Time interval between starting the connection to the backend server and receiving the first byte of the response header. Approximates backend server processing time.

Backend Last Byte Response Time: Time interval between starting the connection to the backend server and receiving the last byte of the response body. This is the sum of backend first byte response time and data transfer time, varying by object size and network latency.

Healthy Host Count: Number of healthy backend hosts detected by Application Gateway health probes.

Unhealthy Host Count: Number of unhealthy backend hosts that failed health probe checks.

Backend Response Status: HTTP response codes generated by backend members. This does not include response codes generated by Application Gateway itself.

Response Status: HTTP response status returned by Application Gateway, including both backend generated and Application Gateway generated responses.

All metrics support filtering by dimensions: Listener, BackendServer, BackendPool, BackendHttpSetting, and HttpStatusGroup. This lets you isolate latency or health issues to specific backend pools or listeners.

Step 2: Enable Diagnostic Logging

Diagnostic logs provide detailed information about every request passing through Application Gateway, including latency breakdowns and backend health status.

Navigate to your Application Gateway resource in the Azure Portal. Under Monitoring, select Diagnostic settings. Click Add diagnostic setting. Configure the following:

Logs to enable:

• ApplicationGatewayAccessLog: Records every request with timestamps, client IP, backend server, response status, and latency
• ApplicationGatewayPerformanceLog: Records performance metrics including backend response time and Application Gateway processing time
• ApplicationGatewayFirewallLog: Records WAF events if WAF is enabled

Destination: Send logs to a Log Analytics workspace for querying and analysis. Optionally send to a Storage Account for long term retention or Event Hub for real time streaming.

Click Save. Logs begin flowing within 5 to 10 minutes.

Example diagnostic setting configuration via Azure CLI:

az monitor diagnostic-settings create \
  --resource /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/applicationGateways/{gateway-name} \
  --name AppGwDiagnostics \
  --workspace /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.OperationalInsights/workspaces/{workspace-name} \
  --logs '[{"category": "ApplicationGatewayAccessLog", "enabled": true}, {"category": "ApplicationGatewayPerformanceLog", "enabled": true}]' \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

This command enables both access and performance logs and sends all metrics to the specified Log Analytics workspace.

Step 3: Query Latency Metrics in Azure Monitor

Once diagnostic settings are enabled, query latency metrics to identify slow requests and backend bottlenecks.

Navigate to Azure Monitor in the portal. Select Metrics. Choose your Application Gateway as the scope. Select the following metrics one at a time to visualize:

• Application Gateway Total Time
• Backend First Byte Response Time
• Backend Last Byte Response Time
• Backend Connect Time

For each metric, apply filters by BackendPool or BackendServer to isolate specific backends. Set the time range to Last 24 hours or Last 7 days depending on your investigation scope. Use Average, Maximum, and 95th percentile aggregations to understand both typical and worst case latency.

Example query in Log Analytics to find requests with high backend response time:

AGWPerformanceLogs
| where TimeGenerated > ago(24h)
| where backendFirstByteResponseTime_s > 1000
| project TimeGenerated, host_s, backendPool_s, backendServer_s, backendFirstByteResponseTime_s, backendLastByteResponseTime_s
| order by backendFirstByteResponseTime_s desc
| take 50

This query returns the top 50 requests in the last 24 hours where backend first byte response time exceeded 1000 milliseconds. The results show which backend servers and pools are slow.

Step 4: Monitor Backend Health with Health Probes

Application Gateway uses health probes to determine if backend servers are healthy. Unhealthy backends are automatically removed from the load balancing rotation until they pass health checks again.

Navigate to your Application Gateway resource. Under Settings, select Backend health. This view shows the real time health status of every backend in every backend pool. Each backend displays as Healthy, Unhealthy, or Unknown with a diagnostic message explaining the failure reason.

Common unhealthy reasons include:

• Backend server returned an invalid HTTP status code (not 200 to 399 by default)
• Health probe timeout — backend did not respond within the configured timeout period
• Connection refused — backend server not listening on the configured port
• DNS resolution failure for FQDN based backends

To configure or modify health probes, go to Settings and select Health probes. Click Add to create a custom probe or edit an existing probe. Configure:

• Protocol: HTTP or HTTPS
• Host: Hostname sent in the probe request
• Path: URL path for the health check endpoint
• Interval: Time between probe attempts in seconds (default 30)
• Timeout: Time to wait for a response before marking the probe as failed (default 30)
• Unhealthy threshold: Number of consecutive failed probes before marking backend as unhealthy (default 3)

Example health probe configuration:

Protocol: HTTPS
Host: api.example.com
Path: /health
Interval: 15 seconds
Timeout: 10 seconds
Unhealthy threshold: 2

This probe checks the /health endpoint every 15 seconds and marks a backend unhealthy after 2 consecutive failures.

Step 5: Set Up Alerts for Latency and Unhealthy Backends

Alerts notify your team when latency exceeds thresholds or backends become unhealthy.

Navigate to Azure Monitor and select Alerts. Click Create and select Alert rule. Choose your Application Gateway as the resource scope.

For latency alerts, configure:

• Metric: Application Gateway Total Time or Backend Last Byte Response Time
• Operator: Greater than
• Threshold: Set based on your SLA (e.g., 2000 milliseconds for 2 second response time)
• Aggregation: Average or 95th percentile
• Evaluation period: 5 minutes
• Frequency: Every 1 minute

For backend health alerts, configure:

• Metric: Unhealthy Host Count
• Operator: Greater than
• Threshold: 0 (alert if any backend is unhealthy) or a specific count
• Aggregation: Average or Maximum
• Evaluation period: 5 minutes
• Frequency: Every 1 minute

Add action groups to send notifications via email, SMS, webhook, or integrate with tools like infrastructure monitoring platforms for centralized alerting.

Example alert rule configuration via Azure CLI:

az monitor metrics alert create \
  --name HighBackendLatency \
  --resource-group {resource-group} \
  --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/applicationGateways/{gateway-name} \
  --condition "avg BackendLastByteResponseTime > 2000" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action {action-group-id}

This creates an alert that fires when average backend last byte response time exceeds 2000 milliseconds over a 5 minute window.

Step 6: Correlate Latency with Backend Performance

Application Gateway latency is often caused by slow backend responses, not the gateway itself. Correlate Application Gateway metrics with backend server performance to pinpoint the root cause.

If you monitor backend servers with PHP application monitoring tools, Ruby application monitoring tools, or other language specific APM tools, compare Application Gateway backend response time with backend server reported request duration. A large gap indicates network latency or Application Gateway processing overhead. Close alignment indicates the backend server is the bottleneck.

Example correlation query in Log Analytics:

AGWPerformanceLogs
| where TimeGenerated > ago(1h)
| summarize avgBackendTime = avg(toreal(backendLastByteResponseTime_s)), avgAppGwTime = avg(toreal(applicationGatewayTotalTime_s)) by backendPool_s
| extend networkOverhead = avgAppGwTime - avgBackendTime
| order by networkOverhead desc

This query calculates average backend response time and Application Gateway total time by backend pool, then computes the difference to show network and gateway processing overhead.

Step 7: Use Workbooks for Unified Latency and Health Dashboards

Azure Monitor Workbooks provide customizable dashboards that combine metrics, logs, and health status in a single view.

Navigate to Azure Monitor and select Workbooks. Click New to create a blank workbook or browse templates for Application Gateway. Add sections for:

• Time series charts showing Application Gateway Total Time, Backend First Byte Response Time, and Backend Last Byte Response Time over the last 24 hours
• Bar charts showing Healthy Host Count and Unhealthy Host Count by backend pool
• Tables listing recent requests with high latency from AGWPerformanceLogs
• Heat maps showing latency distribution by listener and backend pool

Pin the workbook to your Azure Dashboard for quick access during incidents.

Example workbook query for unhealthy backend summary:

AGWAccessLogs
| where TimeGenerated > ago(6h)
| where backendStatus_s != "200"
| summarize count() by backendPool_s, backendServer_s, backendStatus_s
| order by count_ desc

This query counts non 200 backend responses by pool and server over the last 6 hours, highlighting which backends are generating errors.

Troubleshooting Common Issues

High Application Gateway Total Time but normal Backend Last Byte Response Time

This indicates Application Gateway processing overhead or network latency between the client and Application Gateway. Check:

• WAF rule evaluation time if WAF is enabled
• SSL/TLS negotiation time for HTTPS listeners
• Network latency between client and Application Gateway frontend IP

Intermittent Unhealthy Host Count spikes

This often indicates backend server resource exhaustion or transient network issues. Check:

• Backend server CPU and memory utilization during spike periods
• Health probe timeout and interval settings — increase timeout if backends occasionally respond slowly
• Network security group rules that may be blocking health probe traffic

Backend First Byte Response Time consistently high

This points to slow backend application processing. Investigate:

• Database query performance with JavaScript application monitoring tools or backend APM
• Backend server thread pool exhaustion
• Slow external API calls from backend services

Unhealthy Host Count remains above zero despite backends responding

Check:

• Health probe path returns a valid HTTP status code (200 to 399 by default)
• Backend server listens on the correct port and protocol configured in the backend pool
• Host header sent by health probe matches the backend server’s virtual host configuration
• Backend server firewall allows traffic from Application Gateway subnet

Backend Response Status shows 502 or 504 errors

This indicates backend connection or timeout issues. Verify:

• Backend servers are running and reachable from Application Gateway subnet
• Backend HTTP settings timeout is sufficient for backend response time
• Backend server not rate limiting or blocking Application Gateway IP addresses

Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve. Features, pricing, and plan limits can change over time. Always verify the latest information directly with the vendor before making purchasing or deployment decisions.

Frequently Asked Questions