What is recorded
Each entry is one request. The table shows the newest entries first and loads older ones as you scroll, and clicking a row opens the full record.
The full record also includes the API key ID for key-based requests, an impersonator ID when a support session acted on the principal’s behalf, any error code and message, and the request parameters.
Filtering
The page defaults to the last 14 days. Pick a Timeframe at the top of the sidebar, or drag across the chart to zoom into a narrower window. The chart stacks request counts by status class (2xx, 3xx, 4xx, 5xx, and requests with no recorded status) over the selected range. The sidebar filters the table and the chart together, and each value shows how many entries it would match:
Filters live in the page URL, so a filtered view can be shared as a link. Clicking a value in the table adds it as a filter.
What is not recorded
Request parameters are filtered to a fixed list of structural fields - identifiers, names, resource and action names, table and namespace names, paging and status fields. SQL text, scripts, chat messages, connection settings, credentials, and uploaded files are never written to the audit log, and a request body over 16 KiB is omitted. Where something was filtered, the record says so instead of showing an empty value. Reading the audit log is itself an audited request.Permissions
Audit logs are an IAM resource with two actions, both on the organization-wide scope Audit logs → All audit logs:OrganizationAdmin holds both, SecurityAdmin holds Describe, and UserAdmin holds Manage grants. There is no per-entry scope. See Resources and actions.
The permission definitions ship with the system-managed roles today. Enforcement of Describe on the audit page follows once every organization’s system-managed roles have been backfilled; until then the page is available to members of the organization.