Correlation Trace
What this screen is for
One request in your tenant rarely produces one record. A call can reach several of the platform's services, and each records what it did on its own trail — so the account of what happened is spread across your tenant's trails and ordered only by time. This screen gathers it back: you give it a correlation identifier and it puts every record of yours 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 your Audit Log rather than from here.
What must exist first
This screen has no entry of its own in your navigation. You reach it by selecting Trace request on a record in one of the activity panels, or by opening it at its address and typing an identifier into the search box. The identifier is part of the address, so a trace is a link you can send to someone who may read the same trails.
- The permission to trace a request by its correlation identifier. The built-in tenant administrator and tenant auditor roles hold it; the key manager role does not, so a key manager needs a role that adds it.
- An identifier to trace. Every event detail on your Audit Log shows the correlation identifier of the request that produced it, and Trace request is offered directly on a row in the activity of a key, an application and a user.
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.
What the result covers
Everything the timeline shows belongs to your tenant. The identifier itself is not checked against your tenant — one request legitimately crosses services, so there is no single tenant to check it against — but the records that come back are confined to yours, on every part of the timeline.
A consequence worth expecting: an identifier whose request also touched another tenant returns only your side of it, and the timeline says nothing about the part you cannot see. A gap in the timing is therefore not evidence that nothing happened in between.
Reading what came back
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.
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.
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.
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 within your tenant — not that the request never happened, and not that the identifier is wrong. Check the identifier first, then whether the records you expect are on a trail this screen does not place on the timeline.
Using it sparingly
The whole matching set is returned at once: there is no window and no paging. It is built for one request you are investigating, not for reviewing a period; your Audit Log is the screen for that, and it is also where you set a date range, filter and export.
How it relates to other screens
The trail these records come from, where every event detail shows the correlation identifier this screen takes:
The three places that offer Trace request directly on a record:
The cryptographic actor a traced operation is attributed to: