GitHub Audit Log: Search, Export, and Stream

Last verified on Nov 8, 2026.

The GitHub audit log is the record of who changed what in your organization or enterprise: repository visibility, deploy keys, member roles, branch protection, secret scanning. It is the first place to look when a repository goes public that should not have, or when a new key appears on a repository nobody remembers touching. This guide covers what is in it, how to search it, how to pull it through the API, and which events matter most.

What the Audit Log Records

Each entry name is a category followed by an operation, such as repo.create, the create operation in the repo category. An entry shows the organization, the actor who did it, the user affected, the repository, the action, the country, and the time.

Retention depends on where you look. The organization audit log lists events from the last 180 days, and only organization owners can open it. By default the web view shows only the past three months, so to see older events you pass a date range with created. For enterprises, the audit log also lists events within 180 days, but retains Git events (clone, fetch, push) for seven days only. If an investigation might need older data, treat the log as a short buffer and stream it out.

Free and Team plans have a narrower view. The Sazabi integration docs summarize it: Enterprise Cloud has audit events, Git events, and optional API request events; Team plans see audit events in the UI and exports only.

Searching in the Web UI

You find the log under your organization's Settings, in the Archive section under Logs, then Audit log. You cannot search by free text. You build queries from qualifiers, and - negates one:

Qualifiers combine: action:protected_branch actor:octocat created:>=2026-11-01. You can export results as JSON or CSV from the Export menu after filtering, supporting action, actor, user, org, repo, and created. Exports have a hard limit of 100 MB compressed or 10 minutes of processing, so narrow the query first.

Pulling the Log Through the API

Organizations on GitHub Enterprise Cloud can call the REST API. The caller must be an organization owner, and classic tokens need the read:audit_log scope:

curl -sL \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  "https://api.github.com/orgs/my-org/audit-log?phrase=action:repo.access+created:>=2026-11-01&per_page=100"

The response holds 30 events by default from the past three months, so use per_page and the Link header for pagination, and the phrase parameter with created to reach older events. The include parameter takes web (the default), git, or all. Timestamps in the response are UTC epoch milliseconds. Each audit log endpoint is limited to 1,750 queries per hour per user and IP address, so a poller should stay under that and back off on a 403 or 429. Enterprise owners use the equivalent endpoint at /enterprises/{enterprise}/audit-log.

A quick jq view of who did what:

curl -sL -H "Authorization: Bearer $GITHUB_TOKEN" \
  "https://api.github.com/orgs/my-org/audit-log?phrase=action:org.update_member&per_page=100" \
  | jq -r '.[] | [(.created_at/1000|todate), .actor, .action, .user, .permission] | @tsv'

Streaming the Log

Streaming is a GitHub Enterprise Cloud feature. It sends audit and Git events for every organization in the enterprise from the moment you turn it on. Supported destinations are Amazon S3, Azure Blob Storage, Azure Event Hubs, Datadog, Google Cloud Storage, and Splunk. You can configure more than one stream. GitHub notes that a paused stream keeps a buffer of seven days and will resume from one week before the current time if left paused longer, and that a health check runs every 24 hours, with a misconfigured stream needing a fix within six days to avoid dropped events.

Streaming is how you get retention beyond 180 days and Git events beyond seven days, and how you run alerts on events as they happen instead of searching after the fact.

Which Events to Look For

These are the events to check during a security review or an investigation. The names come from GitHub's audit log events reference.

Repository visibility changes. repo.access records that the visibility of a repository changed. A private repository turning public is the most urgent, and the same change is what exposure detection looks for. Query: action:repo.access. The event carries visibility and previous_visibility.

New deploy keys and SSH keys. public_key.create covers both an SSH key added to a user account and a deploy key added to a repository, and public_key.delete the removal. A deploy key added by someone who has no reason to touch that repository is a way to keep access after a password change. Query: action:public_key.

Personal access token activity. The personal_access_token category covers fine-grained tokens: requests (request_created), grants (access_granted), revocations, and the organization's approval and expiration settings. Events carry hashed_token and programmatic_access_type, which help tell which kind of credential performed another action. Query: action:personal_access_token.

Member and role changes. (See also privilege change detection.) org.update_member records an owner/member role change. Also check org.add_outside_collaborator, repo.add_member, repo.update_member, and org.disable_two_factor_requirement. Query: action:org.update_member.

Protected branch changes. protected_branch.destroy (protection disabled), protected_branch.policy_override (a requirement overridden by a repository administrator), protected_branch.update_allow_force_pushes_enforcement_level, and protected_branch.update_admin_enforced. Query: action:protected_branch.

Secret scanning. secret_scanning_alert.create records a detected secret, secret_scanning_alert.resolve an alert closed, and secret_scanning_push_protection.bypass a user bypassing push protection. Also watch repository_secret_scanning_push_protection.disable, because turning the control off is a signal in its own right. Query: action:secret_scanning.

Repository lifecycle and secrets. repo.destroy, repo.transfer_start, and repo.create_actions_secret. Actions secret writes are audited when created, updated, or removed, but GitHub does not audit secret reads.

Turning Events into Investigation Steps

Start from the actor. For any suspicious event, search actor:<login> created:>=<date> and read everything that account did in the window. Then check the hashed_token and programmatic_access_type fields: if the same hashed token appears on events you did not expect, revoke that token. Check country against where the person works. Compare timing against the actor's normal pattern.

Two limits to keep in mind. The log shows administrative and security events, and Git events only for Enterprise Cloud, so it does not show everything an attacker did inside the code. And because Git events are kept seven days at the enterprise level, a clone from last month will not be there unless you were streaming.

Using the Audit Log with Sazabi

Sazabi, an AI-native observability and security platform, accepts the GitHub Enterprise Cloud audit stream through GitHub's Splunk streaming target. Under your enterprise's Settings > Audit log > Log streaming you choose Configure stream > Splunk, enter the intake domain, port 443, and token from Sazabi, and save. Each event keeps GitHub's full JSON, and common fields are also stored as attributes: github.audit.action, github.audit.actor, github.audit.org, github.audit.repo, github.audit.visibility, github.audit.hashed_token, and github.audit.deploy_key_fingerprint. Setup details are in the GitHub audit log source docs, and the GitHub integration page lists the related capabilities. For the concept behind these records, see audit log.