Skip to content

IAM / Concept

Audit log

Updated · 4 min read

Which access changes the audit log records, the fields of each entry, who can read it, and how to page through it with the GraphQL API.

On this page5 sections

The audit log records changes to access in your organization: who did what, to whom, and when. Entries can’t be changed or deleted through the API. You read the log with the auditLogEntries GraphQL query; the CLI has no command for it.

What’s recorded

The audit log records these seven actions. Each one is recorded when the change succeeds.

ActionRecorded whenTarget
iam.role.assignA role is assigned, including when an invite grants a role to an existing accountThe principal
iam.role.revokeA role is revokedThe principal
iam.member.removeA member is removedThe principal
iam.org_invite.createA pending invite is stored for an email address without an accountThe email address
iam.org_invite.revokeA pending invite is canceledThe invite ID
iam.service_account.createA service account is createdThe service account’s principal
iam.service_account.revokeA service account is revokedThe service account’s principal

The audit log doesn’t record organization or project lifecycle changes, resource changes such as launching an instance, or refused requests. Writing an entry never blocks the change itself: if an entry can’t be written, the change still takes effect, so in rare cases an action is missing from the log.

Entry fields

Each entry has these fields.

FieldDescription
idUnique ID of the entry.
orgIdThe organization the action happened in.
projectIdThe project, for a project-scoped role assignment or revocation. Otherwise null.
actorThe principal that performed the action.
actionThe action key from the table above.
targetWhat the action was applied to, as listed in the table above.
outcomeSUCCESS for every recorded action.
occurredAtWhen the action happened, as an RFC 3339 timestamp.
detailsAction-specific context as a JSON string, for example the role URN that was assigned.

Who can read it

Reading the audit log requires the iam.audit_log.list permission on the organization. Both roles/owner and roles/viewer include it, assigned org-wide. See Built-in roles.

Paging through the log

auditLogEntries returns one page of entries, newest first, with a stable order for entries recorded at the same moment. You can read the whole organization’s log, or narrow it to the entries of one project with projectId. Only project-scoped role assignments and revocations carry a project, so a narrowed query leaves out every other action.

The page tells you where you are:

  • entries – the entries on this page.
  • total – how many entries match your query across all pages.
  • offset and limit – the window you were actually served.
  • hasMore – true while entries remain beyond this page. When it’s false, you’ve read to the end.

limit defaults to 100 and is capped at 500. If you ask for more than 500, you get 500, and the limit in the response says so. The cap applies to one page only; every entry is reachable by paging. To get the next page, add the served limit to offset and repeat while hasMore is true.

The following steps show the paging loop.

  1. Request the page with offset 0.
  2. Process its entries, de-duplicating on id.
  3. If hasMore is true, set offset to offset + limit, request the next page and repeat from step 2. If it’s false, you’ve read the whole log.
GraphQL
query {
  iam {
    auditLogEntries(input: { orgId: "<org-id>", offset: 0, limit: 100 }) {
      entries {
        id
        actor
        action
        target
        outcome
        occurredAt
        details
      }
      total
      offset
      limit
      hasMore
    }
  }
}