We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.
The audit log allows organization admins to quickly review the actions performed by members of your organization. It includes details such as who performed the action, what the action was, and when it was performed.
Accessing the audit log
The audit log lists events triggered by activities that affect your organization within the current month and previous six months. Only owners can access an organization's audit log.
By default, only events from the past three months are displayed. To view older events, you must specify a date range with the created parameter. For more information, see "Understanding the search syntax."
In the top right corner of GitHub Enterprise Server, click your profile photo, then click Your organizations.
Next to the organization, click Settings.
In the Settings sidebar, click Audit log.
Searching the audit log
The name for each audit log entry is composed of the action object or category qualifier, followed by an operation type. For example, the repo.create entry refers to the create operation on the repo category.
Each audit log entry shows applicable information about an event, such as:
The enterprise or organization an action was performed in
The user (actor) who performed the action
The user affected by the action
Which repository an action was performed in
The action that was performed
Which country the action took place in
The date and time the action occurred
Note that you cannot search for entries using text. You can, however, construct search queries using a variety of filters. Many operators used when querying the log, such as -, >, or <, match the same format as searching across GitHub Enterprise Server. For more information, see "Searching on GitHub."
Search based on operation
Use the operation qualifier to limit actions to specific types of operations. For example:
operation:access finds all events where a resource was accessed.
operation:authentication finds all events where an authentication event was performed.
operation:create finds all events where a resource was created.
operation:modify finds all events where an existing resource was modified.
operation:remove finds all events where an existing resource was removed.
operation:restore finds all events where an existing resource was restored.
operation:transfer finds all events where an existing resource was transferred.
Search based on repository
Use the repo qualifier to limit actions to a specific repository. For example:
repo:my-org/our-repo finds all events that occurred for the our-repo repository in the my-org organization.
repo:my-org/our-repo repo:my-org/another-repo finds all events that occurred for both the our-repo and another-repo repositories in the my-org organization.
-repo:my-org/not-this-repo excludes all events that occurred for the not-this-repo repository in the my-org organization.
Note that you must include the account name within the repo qualifier; searching for just repo:our-repo will not work.
Search based on the user
The actor qualifier can scope events based on who performed the action. For example:
actor:octocat finds all events performed by octocat.
actor:octocat actor:hubot finds all events performed by octocat or hubot.
-actor:hubot excludes all events performed by hubot.
Note that you can only use a GitHub Enterprise Server username, not an individual's real name.
Search based on the action performed
To search for specific events, use the action qualifier in your query. Actions listed in the audit log are grouped within the following categories:
Contains organization-level configuration activities for Dependabot alerts in existing repositories. For more information, see "About Dependabot alerts."
Contains organization-level configuration activities for Dependabot security updates in existing repositories. For more information, see "Configuring Dependabot security updates."
Contains activities related to GitHub Actions workflows.
You can search for specific sets of actions using these terms. For example:
action:team finds all events grouped within the team category.
-action:hook excludes all events in the webhook category.
Each category has a set of associated actions that you can filter on. For example:
action:team.create finds all events where a team was created.
-action:hook.events_changed excludes all events where the events on a webhook have been altered.
Search based on time of action
Use the created qualifier to filter events in the audit log based on when they occurred. Date formatting must follow the ISO8601 standard, which is YYYY-MM-DD (year-month-day). You can also add optional time information THH:MM:SS+00:00 after the date, to search by the hour, minute, and second. That's T, followed by HH:MM:SS (hour-minutes-seconds), and a UTC offset (+00:00).
When you search for a date, you can use greater than, less than, and range qualifiers to further filter results. For more information, see "Understanding the search syntax."
For example:
created:2014-07-08 finds all events that occurred on July 8th, 2014.
created:>=2014-07-08 finds all events that occurred on or after July 8th, 2014.
created:<=2014-07-08 finds all events that occurred on or before July 8th, 2014.
created:2014-07-01..2014-07-31 finds all events that occurred in the month of July 2014.
Note: The audit log contains data for the current month and every day of the previous six months.
Search based on location
Using the qualifier country, you can filter events in the audit log based on the originating country. You can use a country's two-letter short code or its full name. Keep in mind that countries with spaces in their name will need to be wrapped in quotation marks. For example:
country:de finds all events that occurred in Germany.
country:Mexico finds all events that occurred in Mexico.
country:"United States" all finds events that occurred in the United States.
Using the audit log API
You can interact with the audit log using the GraphQL API.
To ensure your intellectual property is secure, and you maintain compliance for your organization, you can use the audit log GraphQL API to keep copies of your audit log data and monitor:
Access to your organization or repository settings
Changes in permissions
Added or removed users in an organization, repository, or team
Users being promoted to admin
Changes to permissions of a GitHub App
The GraphQL response can include data for up to 90 to 120 days.
For example, you can make a GraphQL request to see all the new organization members added to your organization. For more information, see the "GraphQL API Audit Log."
Audit log actions
An overview of some of the most common actions that are recorded as events in the audit log.
Triggered when the runner application is updated. Can be viewed using the REST API and the UI; not visible in the JSON/CSV export. For more information, see "About self-hosted runners."
Triggered when an existing hook has its configuration altered.
destroy
Triggered when an existing hook was removed from a repository.
events_changed
Triggered when the events on a hook have been altered.
integration_installation category actions
Action
Description
contact_email_changed
A contact email for an integration was changed.
create
An integration was installed.
destroy
An integration was uninstalled.
repositories_added
Repositories were added to an integration.
repositories_removed
Repositories were removed from an integration.
version_updated
Permissions for an integration were updated.
integration_installation_request category actions
Action
Description
create
Triggered when an organization member requests that an organization owner install an integration for use in the organization.
close
Triggered when a request to install an integration for use in an organization is either approved or denied by an organization owner, or canceled by the organization member who opened the request.
issue category actions
Action
Description
destroy
Triggered when an organization owner or someone with admin permissions in a repository deletes an issue from an organization-owned repository.
Triggered when the runner application is started. Can only be viewed using the REST API; not visible in the UI or JSON/CSV export. For more information, see "Checking the status of a self-hosted runner."
self_hosted_runner_offline
Triggered when the runner application is stopped. Can only be viewed using the REST API; not visible in the UI or JSON/CSV export. For more information, see "Checking the status of a self-hosted runner."
self_hosted_runner_updated
Triggered when the runner application is updated. Can be viewed using the REST API and the UI; not visible in the JSON/CSV export. For more information, see "About self-hosted runners."
Triggered when GitHub Actions is enabled for a repository. Can be viewed using the UI. This event is not included when you access the audit log using the REST API. For more information, see "Using the REST API."
Triggered when the runner application is started. Can only be viewed using the REST API; not visible in the UI or JSON/CSV export. For more information, see "Checking the status of a self-hosted runner."
self_hosted_runner_offline
Triggered when the runner application is stopped. Can only be viewed using the REST API; not visible in the UI or JSON/CSV export. For more information, see "Checking the status of a self-hosted runner."
self_hosted_runner_updated
Triggered when the runner application is updated. Can be viewed using the REST API and the UI; not visible in the JSON/CSV export. For more information, see "About self-hosted runners."
Triggered when an enterprise owner or GitHub Support (with permission from a repository administrator) temporarily unlocked the repository. The visibility of the repository isn't changed.
Triggered when a repository transfer is about to occur.
unarchived
Triggered when a repository admin unarchives a repository.
update_actions_secret
Triggered when a GitHub Actions secret is updated.
repository_invitation category actions
Action
Description
repository_invitation.accept
An invitation to join a repository was accepted.
repository_invitation.cancel
An invitation to join a repository was canceled.
repository_invitation.create
An invitation to join a repository was sent.
repository_invitation.reject
An invitation to join a repository was declined.
repository_secret_scanning category actions
Action
Description
disable
Triggered when a repository owner or person with admin access to the repository disables secret scanning for a repository. For more information, see "About secret scanning."
enable
Triggered when a repository owner or person with admin access to the repository enables secret scanning for a repository.
repository_vulnerability_alert category actions
Action
Description
create
Triggered when GitHub Enterprise Server creates a Dependabot alert for a repository that uses a vulnerable dependency. For more information, see "About Dependabot alerts."
dismiss
Triggered when an organization owner or person with admin access to the repository dismisses a Dependabot alert about a vulnerable dependency.
resolve
Triggered when someone with write access to a repository pushes changes to update and resolve a vulnerability in a project dependency.
secret_scanning category actions
Action
Description
disable
Triggered when an organization owner disables secret scanning for all existing repositories. For more information, see "About secret scanning."
enable
Triggered when an organization owner enables secret scanning for all existing repositories.
secret_scanning_new_repos category actions
Action
Description
disable
Triggered when an organization owner disables secret scanning for all new repositories. For more information, see "About secret scanning."
enable
Triggered when an organization owner enables secret scanning for all new repositories.
team category actions
Action
Description
add_member
Triggered when a member of an organization is added to a team.
add_repository
Triggered when a team is given control of a repository.
Triggered when an organization owner enables team discussions for an organization.
workflows category actions
Action
Description
cancel_workflow_run
Triggered when a workflow run has been cancelled. For more information, see "Canceling a workflow."
completed_workflow_run
Triggered when a workflow status changes to completed. Can only be viewed using the REST API; not visible in the UI or the JSON/CSV export. For more information, see "Viewing workflow run history."
created_workflow_run
Triggered when a workflow run is created. Can only be viewed using the REST API; not visible in the UI or the JSON/CSV export. For more information, see "Create an example workflow."
delete_workflow_run
Triggered when a workflow run is deleted. For more information, see "Deleting a workflow run."
disable_workflow
Triggered when a workflow is disabled.
enable_workflow
Triggered when a workflow is enabled, after previously being disabled by disable_workflow.
rerun_workflow_run
Triggered when a workflow run is re-run. For more information, see "Re-running a workflow."
prepared_workflow_job
Triggered when a workflow job is started. Includes the list of secrets that were provided to the job. Can only be viewed using the REST API. It is not visible in the GitHub web interface or included in the JSON/CSV export. For more information, see "Events that trigger workflows."
approve_workflow_job
Triggered when a workflow job has been approved. For more information, see "Reviewing deployments."
reject_workflow_job
Triggered when a workflow job has been rejected. For more information, see "Reviewing deployments."