Global Audit Log
What this screen is for
The Global Audit Log is the platform's trail across every tenant at once: cryptographic operations performed with any tenant's keys, administrative changes on the control plane, and access events such as sign-ins. Each row names the tenant it belongs to, so one screen answers who did what, in which tenant, and with what outcome.
Every record was signed by the service that produced it and verified before it was stored. A record whose signature does not verify is rejected at that point and never written, so it does not appear here and its absence is not announced on this screen. Whether the records already stored are still intact is a different question, answered on Audit Integrity.
Nothing on this screen changes or removes a record. The trails you can see are the ones your permissions admit, and the screen is built from the server's own answer about that rather than from a rule the console keeps.
What must exist first
This is a platform screen, reached in the platform context; opening it inside a tenant sends you to that tenant's Audit Log. The reads are also served only to a caller whose token names the platform tenant.
- At least one platform audit read permission: cryptographic operations, administrative changes, access events, or the one permission that reads all three. The platform super administrator and auditor roles hold all four; the platform viewer holds none, so the sidebar entry is not offered to it.
- Holding none of the four is answered as a refusal rather than an empty page: the screen states that you do not have audit permissions and offers no tab.
- The permission to read platform audit integrity, for the trust indicator beside the title.
Each tab is a trail the server admitted for you. A trail you may not read has no tab — it is not shown disabled, because a disabled control still says the trail exists and is being withheld, which is a different fact.
Decisions you make here
Choosing the window
One window governs the whole screen: the banner, the eight figures, every tab and the export. The choices are All Time, Last 24 Hours, Today (UTC), Last 7 Days and Last 30 Days, and the screen opens on the last 24 hours.
Four of the five send explicit bounds. All Time sends none, and the feed then answers over the window it applies when a caller declares none, which is the last 30 days. A window wider than 365 days is refused rather than narrowed.
Reading the four tabs
All is one ordered stream the server builds over every trail you may read, so a row is never dropped between pages. It carries the tenant of each row, and it walks forward and back without claiming a total, because the stream states none.
Crypto and Admin are each that source's own paged timeline and do state a count. Access is the same ordered stream narrowed to authentication events, so it shows the same rows the mixed view shows for that source.
Narrow any tab with the search box, which sends one query per pause rather than one per keystroke, and with an outcome. Crypto adds an operation filter. Every value offered is one the server projects; there is no list authored in the console, so a filter cannot offer a value no row can match.
Reading the figures
The health banner and the eight cards are all measured over the window on screen, and each names that window. A figure says which of three things it is: a measurement, a read that failed, or a trail you may not read. None of them is rendered as a zero standing in for the others, and a sentence under a figure appears only when the figure above it is a measurement.
Selecting a card narrows the view to what it counts. A card never widens the window you chose; the Today (UTC) card is the one that moves it, and it moves it inward.
Opening an event
Selecting a row opens its detail beside the list. The actor is named by the name its token carried when the operation ran — a user's sign-in name, an application's name — with its identifier underneath.
Request origin states where the request came from: the client address the platform's edge observed, the client's user agent, the request identifier, the path and the method. It appears only when the event had a request; a scheduled rotation had none, and the section is then absent rather than empty. The user agent is whatever the client sent and is shown as plain text.
A cryptographic event also lists Keys used, every key the operation used in the order it signed them, read when you open the event. Its destination key and its authorization details appear only when the record holds them, so a single-key operation shows no destination.
An operation relayed by another platform service records that service's address; the end user's address is on the administrative event with the same correlation identifier.
Exporting
Export downloads one CSV of exactly the rows the mixed view is built from, under the same filters and the same window — the summary in the dialog restates both before you confirm. The file carries the request origin of each row as five columns of its own.
The file stops at a row ceiling set for your installation, 10,000 rows by default. The response states the ceiling, the rows written and whether it stopped early, and the console warns you when it did. A response that states nothing is reported as complete because the rest of the response says so, not because silence was read as reassurance.
Checking integrity
The trust indicator beside the title says whether the platform's audit records were last verified intact. It is read-only here and opens Audit Integrity, where a verification is started and its findings are listed. A failed integrity read degrades in place and never blocks the log.
How it relates to other screens
The verdict beside the title, and the verification that produces it:
Every read of this screen is itself recorded, and that trail of reads is its own screen:
To follow one request across the services it touched, from the correlation identifier in an event's detail:
The same records, seen by the tenant they belong to, and the tenants named in the Tenant column: