• Time zones
• View audit events
• View instance audit events
  • Export to CSV
• View sign-in events
• Filter audit events
• User impersonation
• Available audit events
  • Group events
    • Group management
    • Authentication and authorization
    • Compliance and security
    • CI/CD
    • Code collaboration
  • Project events
    • Project management
    • User management
    • Access control
    • Code collaboration
    • Release management
    • CI/CD
    • Compliance and security
  • GitLab agent for Kubernetes events
  • Instance events
    • Authentication
    • User management
    • Application settings
  • GitLab Runner events
• “Deleted User” events
• Unsupported events

Audit events

Use audit events to track important events, including who performed the related action and when. You can use audit events to track, for example:

• Who changed the permission level of a particular user for a GitLab project, and when.
• Who added a new user or removed a user, and when.

Audit events are similar to the log system.

The GitLab API, database, and audit_json.log record many audit events. Some audit events are only available through streaming audit events.

You can also generate an audit report of audit events.

Time zones

The time zone used for audit events depends on where you view them:

• In GitLab UI, your local time zone (GitLab 15.7 and later) or UTC (GitLab 15.6 and earlier) is used.
• The Audit Events API returns dates and times in UTC by default, or the configured time zone on a self-managed GitLab instance.
• In audit_json.log, UTC is used.
• In CSV exports, UTC is used.

View audit events

Depending on the events you want to view, at a minimum you must have:

• For group audit events of all users in the group, the Owner role for the group.
• For project audit events of all users in the project, the Maintainer role for the project.
• For group and project audit events based on your own actions, the Developer role for the group or project.
• Auditor users can see group and project events for all users.

You can view audit events scoped to a group or project.

To view a group’s audit events:

1. Go to the group.
2. On the left sidebar, select Secure > Audit events.

Group events do not include project audit events. Group events can also be accessed using the Group Audit Events API. Group event queries are limited to a maximum of 30 days.

To view a project’s audit events:

1. Go to the project.
2. On the left sidebar, select Secure > Audit events.

Project events can also be accessed using the Project Audit Events API. Project event queries are limited to a maximum of 30 days.

View instance audit events

You can view audit events from user actions across an entire GitLab instance.

To view instance audit events:

1. On the left sidebar, expand the top-most chevron ().
2. Select Admin Area.
3. On the left sidebar, select Monitoring > Audit Events.

Export to CSV

You can export the current view (including filters) of your instance audit events as a CSV file. To export the instance audit events to CSV:

1. On the left sidebar, expand the top-most chevron ().
2. Select Admin Area.
3. On the left sidebar, select Monitoring > Audit Events.
4. Select the available search filters.
5. Select Export as CSV.

The exported file:

• Is sorted by created_at in ascending order.
• Is limited to a maximum of 100 000 events. The remaining records are truncated when this limit is reached.

Data is encoded with:

• Comma as the column delimiter.
• " to quote fields if necessary.
• New lines separate rows.

The first row contains the headers, which are listed in the following table along with a description of the values:

View sign-in events

Successful sign-in events are the only audit events available at all tiers. To see successful sign-in events:

1. On the left sidebar, select your avatar.
2. Select Edit profile > Authentication log.

After upgrading to a paid tier, you can also see successful sign-in events on audit event pages.

Filter audit events

From audit events pages, different filters are available depending on the page you’re on.

User impersonation

When a user is impersonated, their actions are logged as audit events with additional details:

• Audit events include information about the impersonating administrator. These audit events are visible in audit event pages depending on the audit event type (group, project, or user).
• Extra audit events are recorded for the start and end of the administrator’s impersonation session. These audit events are visible as:
  • Instance audit events.
  • Group audit events for all groups the user belongs to. For performance reasons, group audit events are limited to the oldest 20 groups you belong to.

Available audit events

You can view different events depending on the version of GitLab you have.

Group events

The following actions on groups generate group audit events:

Group management

• Group name or path changed.
• Group repository size limit changed.
• Group created or deleted.
• Group changed visibility.
• User was added to group and with which permissions.
• Removed user from group.
• Project repository imported into group.
• Project shared with group and with which permissions.
• Removal of a previously shared group with a project.
• LFS enabled or disabled.
• Membership lock enabled or disabled.
• Request access enabled or disabled.
• Roles allowed to create project changed.
• Group deploy token was successfully created, revoked, or deleted. Introduced in GitLab 14.9.
• Failed attempt to create a group deploy token. Introduced in GitLab 14.9.
• IP restrictions changed. Introduced in GitLab 15.0.
• Group had a security policy project linked, changed, or unlinked. Introduced in GitLab 15.6.
• An environment is protected or unprotected. Introduced in GitLab 15.8.

Authentication and authorization

• User sign-in using Group SAML.
• Introduced in GitLab 14.5, changes to the following group SAML configuration:
  • Enabled status.
  • Enforcing SSO-only authentication for web activity.
  • Enforcing SSO-only authentication for Git and Dependency Proxy activity.
  • Enforcing users to have dedicated group-managed accounts.
  • Prohibiting outer forks.
  • Identity provider SSO URL.
  • Certificate fingerprint.
  • Default membership role.
  • SSO-SAML group sync configuration.
• Permissions changes of a user assigned to a group.
• 2FA enforcement or grace period changed.

Compliance and security

• Compliance framework created, updated, or deleted. Introduced in GitLab 14.5.
• Event streaming destination created, updated, or deleted. Introduced in GitLab 14.6.
• Changes to push rules. Introduced in GitLab 15.0.
• Changes to streaming audit destination custom HTTP headers. Introduced in GitLab 15.3.
• Instance administrator started or stopped impersonation of a group member. Introduced in GitLab 14.8.

CI/CD

• Shared runners minutes limit changed.
• Group CI/CD variable added, removed, or protected status changed. Introduced in GitLab 13.3.

Code collaboration

• Introduced in GitLab 15.1, changes to the following merge request approvals settings:
  • Prevent approval by author.
  • Prevent approvals by users who add commits.
  • Prevent editing approval rules in projects and merge requests.
  • Require user password to approve.
  • Remove all approvals when commits are added to the source branch.
• Changes to Code Suggestions. Introduced in GitLab 15.11.

Project events

The following actions on projects generate project audit events:

Project management

• Added or removed deploy keys.
• Project created, deleted, renamed, moved (transferred), changed path.
• Project changed visibility level.
• Project export was downloaded.
• Project repository was downloaded.
• Project was archived.
• Project was unarchived.
• Project had a security policy project linked, changed, or unlinked. Introduced in GitLab 15.6.
• Project was scheduled for deletion due to inactivity. Introduced in GitLab 15.0.
• Project deploy token was successfully created, revoked or deleted. Introduced in GitLab 14.9.
• Failed attempt to create a project deploy token. Introduced in GitLab 14.9.
• When strategies for feature flags are changed. Introduced in GitLab 14.3.

User management

• User was added to project and with which permissions.
• Permission changes of a user assigned to a project.
• User was removed from project.
• Users and groups allowed to merge and push to protected branch added or removed. Introduced in GitLab 14.3.

Access control

• Branch protection was added, removed, or updated.
• Failed attempt to create or revoke a project access token. Introduced in GitLab 13.9.
• Allowing force push to protected branch changed. Introduced in GitLab 14.3.
• An environment is protected or unprotected. Introduced in GitLab 15.8.
• User password required for approvals was updated. Introduced in GitLab 14.2.
• Project access token was successfully created or revoked. Introduced in GitLab 13.9.

Code collaboration

• Default description template for merge requests is updated. Introduced in GitLab 15.0.
• Merge commit message template is updated. Introduced in GitLab 15.0.
• Squash commit message template is updated. Introduced in GitLab 15.0.
• Delete source branch option by default enabled or disabled. Introduced in GitLab 14.9.
• Squash commits when merging is updated. Introduced in GitLab 14.9.
• All discussions must be resolved enabled or disabled. Introduced in GitLab 14.9.
• Commit message suggestion is updated. Introduced in GitLab 14.9.
• Automatically resolve merge request diff discussions enabled or disabled. Introduced in GitLab 14.9.
• Show link to create or view a merge request when pushing from the command line enabled or disabled. Introduced in GitLab 14.9.
• When merge method is updated. Introduced in GitLab 14.9.
• Merge trains enabled or disabled. Introduced in GitLab 14.9.
• Code owner approval requirement on merge requests targeting protected branch changed. Introduced in GitLab 14.3.
• Permission to modify merge requests approval rules in merge requests was updated. Introduced in GitLab 14.2.
• New approvals requirement when new commits are added to an MR was updated. Introduced in GitLab 14.2.
• Added or removed users and groups from project approval groups. Introduced in GitLab 13.2.
• Permission to approve merge requests by committers was updated. Introduced in GitLab 12.9.
  • Message for event changed in GitLab 14.6.
• Permission to approve merge requests by authors was updated. Introduced in GitLab 12.9.
• Number of required approvals was updated. Introduced in GitLab 12.9.

Release management

• Release was added to a project.
• Release was updated.
• Release was deleted. Introduced in GitLab 15.3.
• Release milestone associations changed.

CI/CD

• Project CI/CD variable added, removed, or protected status changed. Introduced in GitLab 13.4.
• When default branch changes for a project. Introduced in GitLab 13.9.
• Pipelines must succeed enabled or disabled. Introduced in GitLab 14.9.
• Skipped pipelines are considered successful enabled or disabled. Introduced in GitLab 14.9.
• Status check is added, edited, or deleted. Introduced in GitLab 15.0.
• Merged results pipelines enabled or disabled. Introduced in GitLab 14.9.

Compliance and security

• Created, updated, or deleted DAST profiles, DAST scanner profiles, and DAST site profiles. Introduced in GitLab 14.1.
• Changed a project’s compliance framework. Introduced in GitLab 14.1.

GitLab agent for Kubernetes events

GitLab generates audit events when a cluster agent token is created or revoked.

Instance events

The following user actions on a GitLab instance generate instance audit events:

Authentication

• Sign-in events and the authentication type such as standard, LDAP, or OmniAuth.
• Failed sign-ins.
• Ask for password reset.
• Grant OAuth access.
• Failed second-factor authentication attempt.
• A user’s personal access token was successfully or unsuccessfully created or revoked.
• A user’s two-factor authentication was disabled.
• A user’s access is locked.
• A user’s access is unlocked.

User management

• Added SSH key.
• Added or removed email.
• Changed password.
• Started or stopped user impersonation.
• Changed username.
• User was added or deleted.
• User requests access to an instance.
• User was approved, rejected, or blocked using the Admin Area.
• User was blocked using the API.
• Administrator added or removed. Introduced in GitLab 14.1.
• Removed SSH key. Introduced in GitLab 14.1.
• Added or removed GPG key. Introduced in GitLab 14.1.
• Enabled Admin Mode. Introduced in GitLab 15.7.
• All group events and project events.
• User was unblocked using the Admin Area or API. Introduced in GitLab 15.11.
• User was banned using the Admin Area or API. Introduced in GitLab 15.11.
• User was unbanned using the Admin Area or API. Introduced in GitLab 15.11.
• User was deactivated using the Admin Area or API. Introduced in GitLab 16.0.
• User was activated using the Admin Area or API. Introduced in GitLab 16.1.

Instance events can also be accessed using the Instance Audit Events API.

Application settings

When a user changes an application setting in an instance, project, or group, that change and the user that made the change are recorded in the audit log.

GitLab Runner events

GitLab generates audit events for the following GitLab Runner actions:

• Instance, group, or project runner is registered.
• Instance, group, or project runner is unregistered.
• Runner is assigned to or unassigned from a project.
• Instance, group, or project runner registration token is reset. Deprecated in GitLab 15.6.

“Deleted User” events

Audit events created after users are deleted are created for “Deleted User”. For example, if a deleted user’s access to a project is removed automatically due to expiration.

Issue 343933 proposes to change this behavior.

Unsupported events

Some events are not tracked in audit events. The following epics and issues propose support for more events:

• Project settings and activity.
• Group settings and activity.
• Instance-level settings and activity.
• Deployment Approval activity.
• Approval rules processing by a non GitLab user.

If you don’t see the event you want in any of the epics, you can either:

• Use the Audit Event Proposal issue template to create an issue to request it.
• Add it yourself.