Azure Application Gateway WAF Insights Reaches GA: Logging Setup and Monitoring Requirements

What WAF Insights is​

WAF Insights gives security and operations teams one place to monitor, investigate and report on WAF activity. It is built as Azure Monitor workbooks, so you can customize and extend it.

The feature began as a public preview. A third-party mirror of Azure Updates dates that preview announcement to February 2026. The mirror describes it as an interactive view of logs and metrics that helps with investigating blocked requests and analyzing attack patterns. It also says the filters and visualizations help identify false positives and streamline WAF tuning.

The two tabs: Monitor and Triage​

Monitor is for continuous visibility. It has two views:

• WAF logs view. It reads the AzureDiagnostics table in a Log Analytics workspace. It charts requests by rule group, actions such as blocked requests, top blocked URIs and top triggered rules. It also lists triggered-rule events with timestamps, hosts, gateway instances and client IPs. Analysts can correlate events by tracking ID and look at the top offending IPs.
• WAF metrics view. It reads Azure Monitor metrics and shows near-real-time activity. That includes total WAF requests, managed-rule matches by association, JavaScript challenge counts and custom-rule matches.

Triage is for investigations. It draws on the same Log Analytics data. Apart from the first visualization, each panel filters on what you picked in the previous one. That gives you a drill-down that narrows from broad scope to individual requests.

• Triage by Rule. You start by choosing the policy scope: Listener, URI Path or Global. You then see triggered rules with rule ID, action, ruleset version, scope and impacted-request count. From there you drill into hosts, URLs and individual transactions. This is the route for finding noisy rules and suspected false positives.
• Triage by URL. You start from a URL path, choose the gateway and policy scope, and see which hosts or IPs are hitting that path and which rules fired. Microsoft's example is a login page.

This is an analysis surface. It does not block anything by itself. Blocking is still done by your WAF policy.

Setup: GA does not mean zero configuration​

Microsoft's documentation is clear about the prerequisite. Diagnostic Settings must be enabled for the Application Gateway associations you want to monitor, or the dashboards show no WAF data. Application Gateway's monitoring guidance backs this up: Azure Monitor Network Insights covers Application Gateway without configuration, but resource logs are different. They aren't collected and stored until you create a diagnostic setting.

The documentation also lists several limitations:

• Ingestion delay. Logs can lag by about 1–5 minutes. Metrics are near real-time.
• Retention. Log retention follows your Log Analytics workspace policy. Metrics retention follows Azure Monitor metrics settings. Match the workspace policy to your compliance and audit needs.
• Cost and speed. Large volumes of diagnostic logs can raise query latency and storage costs.
• Azure Diagnostics mode only. The Learn page says resource-specific tables are not supported. The solution relies on Diagnostic Settings streaming to Log Analytics in Azure Diagnostics mode.

The last point is easy to trip over. The wider Application Gateway monitoring page describes a resource-specific mode, with tables such as AGWAccessLogs and AGWFirewallLogs. It also says the toggle defaults to Resource specific in the diagnostic settings. If your gateway already sends logs to dedicated tables, WAF Insights may show nothing until you add an Azure Diagnostics stream. The monitoring page says you can run multiple diagnostic settings, one using Azure Diagnostics and another resource specific. That is my reading of how the two documents fit together, not something Microsoft states for WAF Insights. Test it in a non-production workspace before changing production logging.

A documentation mismatch to know about​

When this article was written, the Learn page for the feature still carried the preview label. It said WAF Insights for Azure Application Gateway is currently in PREVIEW. The page was last updated February 22, 2026.

I read this as documentation lag. That is an inference. The Learn page cannot confirm the GA announcement either way. The Azure Updates entry is the only evidence for GA here. Until the docs are refreshed, check the current Learn page and your own portal before committing to production runbooks. That also applies to any support-policy assumptions based on the GA label.

What the listing does not say​

The submitted listing does not state any of the following, so don't infer them from the GA label:

• regional availability
• pricing, including any extra Log Analytics ingestion or retention charges beyond what you already pay
• SKU eligibility

For SKU context, Microsoft's overview describes v2 (Standard_v2 and WAF_v2) as the current generation. It says the v1 SKUs retired on April 28, 2026. If you still have v1 gateways, migration matters more than any dashboard. Whether WAF Insights works on a particular gateway is a separate question the listing does not answer.

The WAF metrics documentation also notes that new WAF metrics are only available for Core Rule Set 3.2 or greater, or with bot protection and geo-filtering. That is a statement about metric availability. It is not documented as a prerequisite for every WAF Insights panel. Some panels could look empty on older rulesets, but that is untested here.

Practical checklist​

1. Check that each gateway you want to monitor has a diagnostic setting that sends WAF logs to a Log Analytics workspace in Azure Diagnostics mode.
2. Enable metrics as well as logs. Microsoft's best practices recommend both, to balance visibility and detail.
3. Check workspace retention against audit requirements, and estimate the cost of keeping per-request WAF logs.
4. Use the Monitor tab for daily awareness and the Triage tab during incidents. Microsoft also suggests periodically reviewing noisy rules in Triage by Rule.
5. Set alerts on sudden spikes in WAF metrics, such as challenge or blocked requests. Microsoft lists this among its best practices.
6. Confirm the feature's status and any limitations in your own tenant before relying on it operationally.

Bottom line​

For teams already running Application Gateway WAF, this is a useful consolidation. It puts rule tuning, false-positive hunting and URL-focused investigation into one workbook-based flow. The price is real: you need diagnostic logging in the right mode, a retention plan and a tolerance for Log Analytics costs. GA tells you Microsoft considers the feature production-ready. It does not tell you your logging setup is ready for it.