Review an Alert

An alert or incident usually needs evidence from more than one place: the decision event, the captured request, a human review, a configuration change. This guide shows where each kind of evidence lives, and how to write it up so that someone else can check your conclusion.

For a single blocked request, start with Investigate a Blocked Request.

Start with the reported problem

Write down the approximate time, organization, region, and request or resource ID, and what the reporter expected against what happened.

You need Console access to the relevant records. For CLI decision queries, sign in with verdictan auth login with a role that allows events:read.

1. Select the necessary evidence

You need	Start in
Why a request was allowed or blocked	Decision events
The captured prompt and response	History
A human review decision	Inbox
Who changed a resource, and when	Trail
The applied configuration	Configurations and Gateways

You rarely need all of them. Start with the record closest to the problem.

2. Find the applicable record

For a request, query recent events in the region of the gateway:

verdictan events tail --since 30m --json

Match request_id, time, gateway, and agent. If the response ID and event ID look different, convert the ID.

Note the event_id, verdict, reason_code, and config_version. For a configuration or access change, search Trail instead.

3. Examine the related context

• History, when the captured content explains the result.
• Inbox, when the request created an escalation or approval.
• Configurations, to compare the event's configuration version after a recent rollout.
• Trail, for administrative changes around the same time.

Separate what the records show from what still needs evidence. If capture was off or a record is gone, say so.

4. Write a short review note

Copy this into your incident or review record:

Review note

Problem: What happened, and what was expected?
Scope: Organization, region, gateway/agent, and UTC time window
Evidence: Request/event IDs and links to relevant records
Configuration: Applied configuration ID and version
Finding: What the evidence shows
Limits: Missing records or untested explanations
Next action: What happens next, and who owns it?

Link to the retained records rather than copying them, and leave out credentials and prompt content the reader does not need. If the reviewer needs a file, use Export Evidence.

5. Assign the follow-up

Finding	Follow-up
The enforcement was correct	Tell the application owner the policy result.
The policy is wrong	Add a test and propose a configuration change.
A rollout caused it	Ask the rollout owner whether to roll back.
A human decision is needed	Use the escalation workflow.
The provider or application is at fault	Give its owner the error, request ID, and context.

Verify

The review is ready to hand off when another person can find the evidence, check your conclusion, and see who owns the next step.

Missing evidence

An empty view does not prove that nothing happened. Check the region and time window, capture settings, retention, event delivery, and request family support.

When you reproduce the problem with authorization, read the decision events from the time of the attempt:

verdictan events tail --since 15m --event-type decision --json

If the evidence stays unavailable, record that it is missing rather than stating the explanation as fact.

Next steps

• Export Evidence for a Review: download decision events.
• Trail and Audit Evidence: administrative changes.
• Troubleshooting: gateway and delivery problems.