It’s 2 a.m. A deploy went out, checkout is throwing 403s, and the on-call engineer is paging you because “the firewall is blocking real customers.” You know the drill. Open Log Analytics, paste in the AzureDiagnostics query you keep in a Notes file, remember you renamed the resource group last quarter, fix the ResourceId filter, and finally find the rule ID that’s eating legitimate POST bodies. Twenty minutes gone before you’ve touched the actual problem.
Microsoft just shipped the thing that’s supposed to make that faster. WAF Insights for Azure Application Gateway Web Application Firewall is now generally available, out of preview, production-supported. It’s a built-in dashboard that pulls your WAF logs and metrics into one view inside the policy itself. No workbook to import, no query to maintain, no third-party agent. Here’s what that buys you, and where it quietly doesn’t.
Zero new resources to deploy
This is the part that matters more than the dashboards. WAF Insights isn’t a separate Azure resource. It isn’t a Workbook you have to version-control, it isn’t a managed solution with its own RBAC surface, and it isn’t a partner integration you have to get through procurement. It lives inside the WAF policy resource, you open the policy blade in the portal and the Insights experience is right there alongside it.
For anyone running Application Gateway at landing-zone scale, the “zero new resources” bit is the whole pitch. Every custom Workbook someone built in 2022 is a liability: it drifts, the author left, the KQL references a table schema that Azure deprecated, and nobody notices until it renders blank during an incident. A built-in view that Microsoft maintains is one fewer thing in your estate that rots. Underrated benefit, genuinely.
It combines the two data sources you were already juggling: the firewall logs (blocked requests, which rule matched, the offending bits of the request) and the metrics (request rates, block rates, throughput). You were cross-referencing those by hand across two blades. Now they’re on one.
Two SKU generations, and only one of them is invited
Before you go looking for this on an old gateway: WAF policies attach to the v2 SKU family. If you’re still running a WAF_v1 Application Gateway, you’re not getting WAF Insights, and more to the point you’re on a SKU Microsoft has been steering everyone off of for years. The v1 gateways retire on their own timeline, if that’s you, the dashboard is the least of your migration worries.
Confirm what you’re running before you assume you can use any of this:
If tier comes back WAF_v2, you have a WAF policy resource and you’re in. If it says Standard_v2, you’ve got a gateway with no WAF attached, different conversation. Anything with _v1 in it, go read the retirement docs instead of this article.
Hours to minutes, the number, and the asterisk
The marketing line is “investigation from hours to minutes.” I’m allergic to that framing, but this time it’s roughly fair, with a caveat. The hours were never the analysis. The hours were the plumbing: finding the right workspace, remembering whether you parse the log as AzureDiagnostics or a resource-specific table, re-deriving a block-rate query you wrote six months ago. WAF Insights deletes the plumbing. The four jobs it’s actually built for:
- False positives. Legit request got blocked, you need the rule ID and the matched data to decide whether to tune or exclude. This is the 2 a.m. job, and it’s the one the built-in view handles best.
- Tuning OWASP CRS. You’re moving from Detection to Prevention mode, or bumping the ruleset version, and you need to see what would block before it does.
- Attack-pattern analysis. Slicing blocked traffic by source IP and rule ID to tell a real campaign apart from one scanner with too much time.
- Change validation. You pushed a policy change and want to confirm block rates moved the direction you intended, not the opposite.
Here’s the asterisk nobody puts in the announcement. A dashboard shows you the rule that fired. It does not tell you whether blocking that request was correct. That judgement is still yours, and it’s still the hard part. WAF Insights gets you to the decision faster; it does not make the decision. The engineers who were slow at WAF tuning were slow at the judgement, not the querying, and this changes nothing for them.
$0 to turn the feature on, but the logs were never free
The feature itself doesn’t carry a separate line item. What it reads, though, is the diagnostic data you’re already paying to collect. WAF Insights sits on top of your existing logs and metrics, if you aren’t sending firewall logs anywhere, there’s nothing for it to visualise. The logs are the ones with a meter attached, and that meter is Log Analytics ingestion, same as it’s always been.
So the honest cost statement: the dashboard is free, the fuel is not, and nothing about the pricing of that fuel changed. If you want the investigation experience to actually have data in it, confirm diagnostics are flowing:
No firewall-log category enabled, no story to investigate later. The thing that bites you in six months is discovering that the policy nobody flagged as important was never logging, so the one incident you needed to reconstruct has a hole in it exactly where the attack was. Turn logging on everywhere before you need it, not during the post-mortem.
Three things this quietly makes obsolete
Dig through most mature Azure estates and you’ll find the same three homegrown artefacts around WAF, all now partly redundant:
- The Notes-file Kusto query. The one every senior engineer keeps and pastes into Log Analytics during incidents. Still useful for anything bespoke, but the common cases now have a GUI.
- The custom Azure Monitor Workbook. Someone built a “WAF Overview” Workbook two reorgs ago. It’s beautiful, it’s unmaintained, and its author’s Entra account was offboarded. You can retire a chunk of these.
- The third-party WAF analytics tool. If you were paying a vendor purely to render Application Gateway WAF logs into charts, that spend is now harder to justify. If you were paying them for correlation across your whole estate, SIEM features, and threat intel, keep it, this doesn’t touch that.
One thing I’d push back on: don’t rip out your Log Analytics / Sentinel pipeline because a built-in dashboard appeared. WAF Insights is for interactive investigation on one policy. It is not a replacement for long-term retention, cross-resource correlation, scheduled alert rules, or compliance evidence. Those still live in your workspace and your SIEM. This complements that layer; it does not replace it. Anyone who tells you it does hasn’t been handed an auditor’s log-retention requirement.
And to be precise, because the Azure WAF family confuses everyone: this is Application Gateway WAF. If your edge is Azure Front Door, that’s a different WAF with its own tooling and this announcement isn’t about it. Check which one you’re actually running before you plan a workflow around the wrong product.
The one thing worth doing this week
Open the WAF policy blade for your busiest production gateway and find the Insights view. Confirm it has data in it, which is really a test of whether your diagnostic logging was ever wired up correctly. For half of you that check will surface a policy that’s been silently logging nothing for a year. Fixing that is worth more than any dashboard. The dashboard just told you where to look.
It won’t save you from a bad OWASP exclusion written at 2 a.m. But it’ll get you to the rule ID before the coffee’s cold, and some nights that’s the whole win.