Reading one audit event

Everything recorded about one event sits in its details panel. Read it top to bottom: when, who, what, what changed, then the technical record.

What you'll need

• Access to Audit Logs in the staff console.
• A staff sign-in, and a tenant and a service chosen on Audit Logs.

If an area or a button is missing, your staff role does not include it. Ask a platform administrator to extend your access.

Steps

1. Open the event

   Select a row in the day-by-day list. The panel opens on the right, titled with the event’s plain-language action; the cross closes it.

   

   The details panel of a Tenant suspend event: HIGH, Configuration change, SUCCESS and COMPLETED badges; When with Occurred and Recorded; Who; What with the reason payment overdue; Details with suspensionCategory NON_PAYMENT and previousStatus ACTIVE; and Technical details expanded down to Chain position #14 and Chain hash.

2. Read the badges and the dates

   The badge row carries the severity, category and outcome, then the change status when there is one. Under When, Occurred is the event’s own clock and Recorded is when the trail received it, so a delay stays visible. Hover a date for the exact instant.

3. Read who and what

   Who gives Type, Identity and Name. What gives the Action as a sentence over its raw event name, the Resource with its name and type, and a Reason when one was recorded.

4. Check the change and the details

   What changed appears for edits that recorded a before and after. Details lists the rest of what the service sent, with processing stages and knowledge base ids turned into names.

5. Expand Technical details

   Open Technical details for Service, Correlation ID, Log ID, IP address, Chain position and Chain hash. Copy icons sit beside the ids.

What success looks like

• The badge row, When, Who, What and Technical details appear on every event; Recorded, Reason, IP address, What changed and Details only when the event carries them.
• Anything the producing service did not send shows a dash. A Name the service kept to itself reads Not sent (kept at the source service).
• A copy icon turns into a tick once the value is copied.

Who did it

Type says what kind of actor it was: a user, staff, a service, or API key for a partner integration. For an API key, Identity is the key's reference and Name the name its tenant gave it. Key events themselves, such as API key created, API key regenerated and API key revoked, are on the Security service's trail.

A key event on the Security trail: who acted on the key, and the key itself under Details.

Reading a change

What changed names each field that changed rather than printing two payloads. A list shows each added item as a chip marked with a plus sign and each removed one as a red chip, struck through and marked with a minus sign, with a note such as 3 kept, or Order changed only when items were only reordered. A single value shows the old one struck through, an arrow, then the new one, with (not set) or (removed) for a missing side. A footer counts the fields left alone, and identical sides read No visible difference.

If something goes wrong

Symptom	Likely cause	What to do
No What changed section.	Only some edits record a before and after, such as visibility and enable or disable changes.	Read Details instead.
Chain position and Chain hash show a dash.	The event came from a pipeline worker, which publishes without chain proof.	Expect chain values only from chained producers. See What the trail covers.
A failed processing step does not name the stage in its title.	Failure events keep their own label.	Read the stage row under Details, and note which service you chose.
This event could not be loaded.	The link names an event outside the chosen tenant and service.	Check both, then search for the event again.

Next

• Searching the staff audit trail - finding the event first.
• What the staff audit trail covers - services and event names.