Where are Azure WAF logs — and how to read them
The first time you go looking for WAF logs in Azure, you find nothing — and assume you're in the wrong blade. You're not. There is nothing there yet, and that is the whole answer.
New to cloud? CAMPUX is a free, build-first course. Start here →
Azure WAF does not log anywhere by default — you turn on Diagnostic settings on the Application Gateway or Front Door and send the WAF log category to a Log Analytics workspace (or storage, or Event Hub), then query it with KQL. The firewall log is the one that shows blocked and matched requests. No diagnostic setting means no logs at all.
I have watched more than one engineer open the WAF resource, click through every menu, and conclude the logging is broken. It isn't broken. Azure evaluates every request against your rules whether or not anyone is recording the verdict — and unless you've explicitly wired up a destination, nobody is. The evaluation happens in memory and is thrown away. So the real question isn't "where are the logs," it's "did anyone turn logging on," and the honest answer in most environments I inherit is no.
Why there's nothing to find by default
Azure WAF is a policy attached to one of two front-end resources: an Application Gateway or an Azure Front Door profile. Both are Azure resources, and every Azure resource emits its telemetry through the same pipe: Diagnostic settings. That is the switch that says "take the logs this resource produces and ship them somewhere I can read them." Until you create one, the resource keeps its logs to itself and they expire in memory.
This trips people up because they expect a firewall to log the way an on-prem appliance does — a file on the box you can tail. In Azure the WAF has no box you can log into and no file to tail. Its output only exists if you first tell the platform where to put it. That design is consistent across the whole platform, which is why the traffic and load-balancing services behave the same way — logging is opt-in, per resource, every time.
Turn logging on: the four clicks
The setup is short, and it's the same shape for both products:
- Open the resource that carries the WAF — the Application Gateway, or the Front Door profile. Not the WAF policy itself; the front-end resource it's attached to.
- Go to Diagnostic settings (under Monitoring in the left menu) and click Add diagnostic setting.
- Tick the WAF / firewall log category. On Application Gateway that's the firewall log (and optionally the access and performance logs); on Front Door it's the web application firewall log. Give the setting a name.
- Pick a destination. For anything you intend to query, choose Send to Log Analytics workspace. Storage account is for cheap long-term retention; Event Hub is for streaming to a SIEM. You can tick more than one.
Save it, then wait. Logs are not retroactive — you only capture requests that arrive after the setting exists, and there's usually a few-minutes lag before the first rows appear in the workspace. If you turned this on in response to an incident that already happened, you have missed it; the data was never recorded.
The WAF was judging every request all along. It just wasn't writing anything down until you asked it to.
Where the logs land, and what the tables are called
Once the setting sends to Log Analytics, the WAF rows become a table you query with KQL. Which table depends on the product. These are the resource-specific table names as of 2026 — verify the exact spelling in your own workspace, because older setups route everything into the shared AzureDiagnostics table instead of dedicated ones, and Microsoft has renamed these before.
| Application Gateway WAF | Front Door WAF | |
|---|---|---|
| Firewall log (blocked / matched) | ApplicationGatewayFirewallLog |
FrontDoorWebApplicationFirewallLog |
| Access log (every request) | ApplicationGatewayAccessLog |
FrontDoorAccessLog |
| Action value for a block | Blocked (also Matched in detection mode) |
Block (also Log / AnomalyScoring) |
| Legacy fallback table | AzureDiagnostics — older diagnostic settings put both products here; filter on Category. |
|
The firewall log is the one you almost always want. It records the requests the WAF acted on — the rule that fired, the verdict, and enough of the request to identify it. The access log is broader: it records every request the front end handled, blocked or not, which is useful for context but noisy when you're hunting a specific block.
Reading it with KQL
In the Log Analytics workspace, open Logs and run a query against the firewall table. Here's a starting point for Application Gateway that pulls the fields worth reading and filters to actual blocks in the last day:
// Application Gateway — blocked requests, last 24h
ApplicationGatewayFirewallLog
| where TimeGenerated > ago(24h)
| where action_s == "Blocked"
| project TimeGenerated, clientIp_s, requestUri_s, ruleId_s, message, action_s
| order by TimeGenerated desc
The useful fields, whichever product you're on, are roughly the same handful:
| Field | What it tells you |
|---|---|
ruleId | Which managed or custom rule fired — your first clue whether it's a real attack signature or a legit request tripping an over-eager rule. |
action | Blocked/Block vs Matched/Log — did the WAF stop the request or just note it (detection mode). |
clientIp | The source address. A spread of IPs hammering one path reads like an attack; one office IP reads like your own app breaking. |
requestUri | The path and query that was flagged — the single most useful field for deciding whether the block was right. |
Field names carry Log Analytics type suffixes like _s (string) that vary by table and schema version, so if a column doesn't resolve, remove the projection and run the bare table name first to see the real column names. On Front Door the same query works with FrontDoorWebApplicationFirewallLog and action_s == "Block". A capstone like the enterprise web platform build is a good place to wire this end to end on infrastructure you actually own.
A WAF in prevention mode with nobody reading the logs is the quiet failure I see most. It feels safe — requests are being blocked — but two things rot underneath it. One: a legitimate request your own app depends on gets blocked by an over-broad rule, and because no one is watching the firewall log, it surfaces days later as a mysterious "the feature is down for some users." Two: a real, targeted attack probes you for a week, and every block is a signal you never read. Prevention mode without eyes on the log is a smoke detector with the battery out. It looks installed. It isn't protecting anyone.
Detection vs prevention, and why it matters for logs
Before you flip a new WAF policy to prevention, run it in detection mode for a while with logging on. In detection mode the WAF evaluates rules and writes the verdict to the firewall log but does not block — the action reads Matched or Log instead of Blocked. That's your baseline. You watch what would have been blocked, spot the rules that would break your own traffic, tune or disable them, and only then switch to prevention. Skipping this step is how a WAF takes down a legitimate feature on day one. And you can only do it if logging is on — which loops back to the whole point of this note.
If you're weighing the WAF against Azure's other network filtering, the split between the two is worth understanding before you decide what to log where — I covered it in Azure Firewall vs WAF, and the choice between the two WAF front ends in Front Door vs Application Gateway.
A short checklist
- Found nothing in the WAF blade? That's expected. Logs live in a Log Analytics workspace, not on the WAF resource.
- Diagnostic setting exists? Check on the Application Gateway / Front Door resource, under Monitoring. No setting, no logs.
- Right category ticked? The firewall / WAF log holds blocks and matches; the access log holds everything.
- Querying the right table?
ApplicationGatewayFirewallLogorFrontDoorWebApplicationFirewallLog, or fall back toAzureDiagnosticson older settings. - Someone actually reading it? Set an alert on block volume so the log isn't just data no one opens.
Common questions
Does Azure WAF log by default?
No. A WAF on Application Gateway or Front Door writes nothing until you create a Diagnostic setting on that resource and point the WAF/firewall log category at a destination — a Log Analytics workspace, a storage account, or an Event Hub. Until you do that, blocked and matched requests are evaluated but never recorded, so there is nothing to read after the fact.
How do I see blocked requests in Azure WAF?
Send the firewall log to a Log Analytics workspace, then query it with KQL and filter on the action column for Blocked (Application Gateway) or Block (Front Door). Each row gives you the client IP, the request URI, the rule that fired (ruleId), and the action taken, which is enough to tell a real attack from a legitimate request the WAF broke.
Where do Front Door WAF logs go?
Wherever you send them in the Front Door profile's Diagnostic settings. Turn on the WAF log category and route it to a Log Analytics workspace, storage, or Event Hub. In Log Analytics the Front Door WAF rows land in the FrontDoorWebApplicationFirewallLog table (verify the exact name in the portal as of 2026), separate from the Application Gateway tables.
What KQL table holds Azure WAF logs?
It depends on the product. Application Gateway WAF rows land in ApplicationGatewayFirewallLog, and its access log lands in ApplicationGatewayAccessLog. Front Door WAF rows land in FrontDoorWebApplicationFirewallLog. These are the resource-specific table names as of 2026 — confirm them in your workspace, since older setups may use the shared AzureDiagnostics table instead.