> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit log

> Every change made inside your aiAxonIQ organization — who did what, when, and how to export it for a compliance review.

The audit log records changes to your organization: users invited and removed,
roles changed, license keys created and revoked, alert rules and dashboards
edited, and any support access granted.

<Info>
  **Reading the audit log requires the Auditor, Admin or Owner role.** Auditor
  exists specifically for this: it grants read access to the audit log and
  **cannot change anything at all**, which is exactly what a compliance
  reviewer should hold. See [Roles and permissions](/concepts/roles).
</Info>

## What is recorded

| Category           | Examples                                                               |
| :----------------- | :--------------------------------------------------------------------- |
| **Membership**     | Invitations, removals, role changes                                    |
| **Credentials**    | License keys created and revoked                                       |
| **Configuration**  | Alert rules, dashboards, SLOs, synthetic checks, notification channels |
| **Account**        | Plan changes, organization settings                                    |
| **Support access** | Every session in which aiAxonIQ staff accessed your organization       |

Each entry carries the actor, the action, the resource type and identifier, and
the time.

## Support access is in your log

<Note>
  **When aiAxonIQ support is granted time-limited access to your organization
  to investigate a ticket, that appears here** — who, when, and for how long.

  It is deliberately in *your* audit log rather than only in an internal one.
  An access record you cannot read is a policy; one you can read is a control.
</Note>

## Filtering

Filter by action type and by resource type, both of which are enumerable — so
you can see what kinds of events exist rather than guessing at strings. An
individual entry can be opened for its full detail.

The common questions:

* *Who revoked that key?* Filter to credential actions.
* *What changed before this alert started misfiring?* Filter to the rule's
  resource type around the time it began.
* *Who has been added to this organization this quarter?* Filter to membership.

## Export

The log can be exported for a compliance review or to keep alongside your own
records.

<Warning>
  **Export before you need it, not after.** The audit log is not exempt from
  retention. If your compliance process requires records for longer than the
  platform keeps them, a periodic export is the mechanism — there is no
  archive to request later.
</Warning>

## What is not here

<Warning>
  **The audit log records control-plane changes, not telemetry access.** It
  does not record every dashboard someone viewed or every log search someone
  ran.

  If your requirement is "prove nobody read this data", that is a boundary
  question rather than a logging one — the answer is a separate organization,
  because every member of an organization can read all of its telemetry. See
  [Organizations and multi-tenancy](/concepts/organizations).
</Warning>

Detections about your *systems* — authentication failures, exposed secrets,
runtime threats — are [security events](/guides/security/overview), which is a
different surface. During an investigation you usually want both.

## Next

<CardGroup cols={3}>
  <Card title="Roles and permissions" icon="user-shield" href="/concepts/roles">
    The Auditor role, and who may grant it.
  </Card>

  <Card title="Security events" icon="shield-halved" href="/guides/security/overview">
    Detections over your telemetry.
  </Card>

  <Card title="Organizations" icon="building" href="/concepts/organizations">
    Where the real access boundary is.
  </Card>
</CardGroup>