NinjaFirewall logs every decision it makes: rule ID, action (blocked, sanitised, allowed), source IP, request URI, HTTP method, and timestamp. The Event Log screen in the native admin paginates those rows with a simple filter set, which works for case-by-case lookups and falls short when an operator needs to see which rule fired most this week across which URLs.

SleekView reads the NinjaFirewall event log table directly. Sort by stamp to see the last hour. Filter by rule ID to follow one signature, by action to isolate blocks from sanitisations, by IP to see one attacker's full path through the site, by URI to spot the targeted endpoints. The same data shows up in saved views the team reopens with one click instead of rebuilding the filter set every morning.

The firewall keeps owning the rules, the engine, and the request-time decisions. SleekView only adds the triage surface, so the rich event log NinjaFirewall already writes becomes a queryable workspace inside WordPress.

NinjaFirewall is exact about per-request decisions, which is exactly what an admin wants from a WAF. The trade-off is that the resulting log is presented row by row. Anyone asking which rules fired the most this week, or which IPs hit which URLs around a specific minute, has to export to CSV and re-tool.

SleekView reads the same log table the firewall already writes and renders it as a sortable, filterable workspace inside WordPress. The firewall keeps deciding what reaches PHP. The team gets a triage surface with saved views, role scoping, and CSV exports that honour the active filter set, so the value of the log finally matches the precision of the events captured in it.