Skip to main content
Events are the audit trail for Averta runtime decisions. Use them to confirm traffic is protected and to debug blocks, tool restrictions, tool-result failures, and output decisions.

What an Event Means

Each event is one checkpoint decision. A single model turn can produce several events:
Not every turn produces every checkpoint. If the model does not call a tool, there will be no tool-call or tool-result event. If the model returns another tool call, output may not run yet because the turn is not final.

Fields to Check First

Investigation Order

  1. Filter to the time range around your test run.
  2. Filter by API key prefix or environment.
  3. Search for conversationId, requestId, or traceId.
  4. Narrow by checkpoint if you know where the failure happened.
  5. Inspect block, restrict_tools, and rewrite decisions first.
Starting from policy settings before you find the relevant event is usually wasted time. Find the event, then tune the policy.

Decision Meanings

For restrict_tools, inspect blocked tool names and then review the attached tool exposure policy.

Empty Events Checklist

If you expected events and the table is empty:
  • confirm your app uses a wrapped client or calls POST /v1/decide
  • confirm AVERTA_API_KEY is set in the same process that calls the provider
  • confirm the key is not revoked
  • confirm the key has an attached policy
  • confirm your app sends traffic to https://api.averta.io or the intended AVERTA_BASE_URL
  • confirm you are looking at the right organization and time range
  • add onDecision logging to prove the SDK is receiving decisions

Correlate with SDK Logs

Add onDecision while debugging:
Then search Events for the same conversationId, requestId, or traceId.

Common Investigations

Next Steps

Checkpoints

Understand the lifecycle stage behind each event.

API keys

Confirm which key and policy produced the event.