Correlation Trace
What this screen is for
One request rarely produces one record. A single call can reach several services, and each of them records what it did on its own trail — so the account of what happened is spread across trails and tenants, ordered only by time. This screen gathers it back: you give it a correlation identifier and it puts every record carrying that identifier on one timeline, oldest first, with the gap in milliseconds from the record before it.
A correlation identifier is a UUID. A service adopts an incoming X-Correlation-Id header when it is a UUID in its 36-character hyphenated form, in any letter case, and records it in lower case; any other value is replaced by a newly generated one. The value then travels with the request and is stamped on every record it produces. You do not create one here; you take one from a record you are already looking at.
The timeline is built from the cryptographic and the administrative trails. An event recorded only on the access trail is not placed on it, so a sign-in is followed from the Global Audit Log rather than from here.
What must exist first
This screen has no sidebar entry on the platform plane. You reach it by address — the identifier is part of the address, so a trace is a link you can send to someone — or you open the screen empty and type an identifier into the search box.
- The permission to trace a request by its correlation identifier, or the permission to read all platform audit trails. The platform super administrator holds both; the platform auditor holds only the second and reaches this screen through it. The platform viewer holds neither and reaches no trace at all. Holding some other platform audit permission — cryptographic operations alone, for instance — does not reach this screen.
- An identifier to trace. Every event detail on an audit log shows the correlation identifier of the request that produced it, and the activity panels inside a tenant offer Trace request directly on a row.
No tenant is checked against the identifier, because one request legitimately crosses services and tenants and there is no single tenant to check it against. What you may see is decided by the permission you hold, never by the identifier.
Decisions you make here
Tracing an identifier
Paste the identifier and select Trace. The identifier becomes part of the address, so the result is reproducible and the back button means something, and Copy puts the identifier back on your clipboard for a ticket.
Reading what came back, and what it covers
Trace Summary states Total Events, Crypto Ops, Admin Actions, Total Duration — the span from the first record to the last — and a Status that reads FAILURE when any record on the timeline failed, Performed — result withheld when none failed but an operation's result was withheld, and SUCCESS otherwise.
An operation answered with a 503 because its own audit record could not be confirmed may still have been performed. The service then records that its result was withheld, and the timeline shows that operation once, reading Performed — result withheld rather than the success its own record states. A withheld operation is not billed.
The breadth of the result is the decision this screen makes for you, and it follows the permission rather than the plane. Only the permission to read all platform audit trails returns records belonging to every tenant. With the correlation permission alone, the timeline is confined to your own tenant's records even on this screen, and the summary counts only those.
Reading a record on the timeline
A cryptographic record names the operation, the key, the algorithm, the client and how long it took.
An administrative record says what changed: a rotation reads Rotation v1 → v2 with Manual or Scheduled, a failed rotation gives its reason, and any other change lists each field before → after. Performed by names the scheduler, the system or the kind of actor that started a rotation, and keeps the recorded identifier whole and copyable. Subject names a key by its key identifier, with the key record's identity beside it; any other object is named by its kind and identity. Each record also names its tenant, which is what makes a cross-tenant trace readable.
Two things about the object of an administrative record are worth knowing before you cite one. The kind is a reduced form of the producer's own name — a key alias entity is reduced to KEYALIAS — and the reduction cannot be reversed, so it is not the value an integrity check is answered from.
The identity is shown exactly as it was signed; where an administrative event acts on nothing durable, the producing service derives a stable identifier from the operation's name, so a well-formed identifier here may correspond to no object anywhere.
Following a relayed operation
A key operation started from the console reaches the cryptographic service through the administrative service. The administrative record carries the operator's own client address, and it is the record that answers who started the operation and from where. Only a key rotation also leaves a cryptographic record: it carries the address of the service that relayed the call, and it shares this identifier with the administrative record. Creating or importing a key leaves no cryptographic record, so its trace returns the administrative record alone.
When nothing comes back
An empty result says no events were found for that identifier. That means no record carrying it exists on the trails you are permitted to read — not that the request never happened, and not that the identifier is wrong. Check the identifier, and check whether the records you expect belong to a tenant your permission does not reach.
Using it sparingly
The whole matching set is returned at once: there is no window and no paging, and a cross-tenant trace reads every partition of the cryptographic trail because the identifier is not what that trail is partitioned by. It is built for one incident, not for browsing a period; the Global Audit Log is the screen for that.
How it relates to other screens
The correlation identifier shown in any event's detail is the value this screen takes, and the trail that record came from:
Whether the records on the timeline are still intact, and whether this read was itself recorded:
The same screen as a tenant operator sees it, confined to their own tenant: