Firewall observability
Inspect firewall actions and understand why a request was allowed, blocked, or challenged.
Firewall observability connects security decisions to request activity.
Use it to:
- Debug a custom rule
- Investigate an attack
- Confirm Attack Mode behavior
- Identify false positives
- Determine whether application code ran
- Measure the impact of a policy change
Firewall events
Firewall and edge request views can include:
- Timestamp
- Request ID
- Project and deployment
- Domain
- Client IP, subject to permissions and privacy controls
- Method and path
- Action
- Rule ID
- Country and ASN, when available
- Response status
Actions
Customer-facing action values you may see include:
Platform protections may also surface actions such as ban or throttle on
blocked or rate-limited traffic.
Use stable machine-readable values when filtering, even when dashboard labels change.
Decision sources
When describing where a decision came from, prefer product concepts:
- Platform protection
- Custom rule
- Attack Mode
- Deployment protection
Do not rely on internal vendor names as part of the public event schema.
Response metadata
For custom-rule denials and some redirect failures, responses may include:
Challenge responses may also include:
Treat these as operational debugging signals. Incoming client copies of security headers are not a trust boundary.
Rule testing
A safe workflow is:
- Create a rule with the Log action.
- Filter events by the rule ID or path.
- Review expected and unexpected matches.
- Refine the rule.
- Change the action to Deny, Challenge, Bypass, or Redirect.
- Continue monitoring after enforcement.
Challenge pass and fail counts reflect verification outcomes at
/.well-known/easel-challenge/verify, not every page view.
Privacy
Client IP and geographic information may be sensitive. Limit access to workspace members who need it for operations, and avoid exporting raw client identifiers into systems that do not require them.