GitHub audit log limitations: retention, gaps, plans

TL;DR. The audit log is the best GitHub evidence you have, and it has hard edges. Retention: 180 days for audit events, 7 days for Git events. Plan: API, Git events and streaming require Enterprise Cloud. IPs: hidden unless an owner enables display. Content: no file contents, no diffs, no record of a workflow reading a secret, no per-user reads of code in the web UI. Scope: personal account security logs are separate. Before you write "no evidence of compromise", check each of these against the export you actually analyzed.

Every investigation report should say what the evidence could and could not show. For GitHub, that list is short but important, and several items depend on your plan and settings, not on the attacker.

Retention

Data	Retention	Source
Organization / enterprise audit events	180 days	About the audit log for your enterprise
Git events (`git.clone`, `git.fetch`, `git.push`)	7 days	same page, and the organization audit log page
Default window of the API	last 3 months unless `created` is specified	REST reference
GraphQL audit log	90 to 120 days of data	Reviewing the audit log (Enterprise Cloud)
Actions logs and artifacts	90 days by default (configurable)	Retention settings
Streamed audit log	as long as your storage keeps it	your bucket / SIEM

What this means in practice: an intrusion discovered three weeks late will have no clone records at all unless you stream. An intrusion discovered seven months late will have almost no GitHub-side evidence. Audit log streaming is the only way to beat both limits.

Plan requirements

Capability	Free / Team	Enterprise Cloud
View and export the organization audit log (UI, JSON / CSV)	yes	yes
Audit log REST and GraphQL API	no	yes
Git events	no	yes (API, export, streaming)
Audit log streaming	no	yes (enterprise)
IP allow list, SAML SSO	no	yes

GitHub states that the audit log API requires Enterprise Cloud, and the same applies to IP allow lists. On Free and Team, the UI export is your main source, and mass cloning can only be inferred indirectly (see repository exfiltration).

Settings that change what you get

IP addresses. GitHub does not display source IPs by default. When an owner enables display, it applies to new and existing events. Even then, IPs are only shown under conditions: organization members acting on private or internal organization resources, and API requests with repository context. Expect gaps.
Token metadata. hashed_token, programmatic_access_type and token_scopes are recorded for token-authenticated events. The data for Git events and for SSH and deploy keys is marked as public preview in GitHub's documentation, and UI and API searches by hashed_token exclude Git events.

What is not recorded

File contents and diffs. The audit log tells you a push happened and a workflow ran. It does not tell you what the workflow file said. A modified workflow has to be inferred from its runs (new branch, secrets printed) and confirmed in the repository history.
Secret reads. Creating, updating and deleting Actions secrets are events. A workflow using a secret during a run is not. The run log archive is the only record of what a step did with it (see Actions secrets leak).
Git operations done through the web or API. Git events exclude them. A pull request merged in the browser pushes to the base branch without a git.push event.
Browsing code in the web UI. Viewing files in the browser does not produce per-file audit events. Archive downloads (repo.download_zip) do.
What happens on runners. The audit log sees runner registration and status, not the commands a job ran on a self-hosted host. Those live in the runner's _diag logs (see self-hosted runner security).
Personal account activity. A user's own security log (sign-ins, 2FA changes, their SSH keys and tokens) is separate from the organization audit log and is not part of its export. The user reviews it themselves, and the analyzer does not read it.
Anything after the attacker leaves GitHub. Cloud keys used in AWS, Google Cloud or Azure show up in those logs (see the cloud pivot).

Limitations of the analyzer itself

The tool inherits every gap above and adds its own:

Heuristics and thresholds. Mass cloning fires at 10 distinct repositories per actor and IP in about an hour. New IP and new country need 24 hours of history per token or actor. A slow attacker, or an export that starts on the day of the intrusion, can stay under them.
Noisy low rules. workflow-new-branch, token-new-ip and actions-secret-created fire on normal work, by design. Read them in context.
No enrichment. No ASN or hosting-provider lookup, no threat intelligence. That keeps everything offline, but you judge the IPs yourself.
Table cap. The event table lists the first 100,000 events. All events are analyzed, and the coverage notes say when the table is truncated.
The Clean verdict means "no rule fired on these logs", not "no compromise". The coverage notes tell you which rules were blind.

Make the next investigation easier

Stream the audit log to storage you control, with retention longer than 180 days.
Enable IP address display.
Set Actions log retention to cover your detection delay, and forward self-hosted runner logs.
Export and archive the Git events during any suspicion. Seven days go fast.
Keep a monthly baseline export so that "new country" has a history to compare with.

FAQ

How long does GitHub keep the audit log?

Organization and enterprise audit events are listed for the last 180 days. Git events are retained for seven days. The API returns the last three months by default unless you add a created qualifier. Streaming to your own storage is the way to keep more.

Is the GitHub audit log available on the Free and Team plans?

Organization owners on every plan can view and export the organization audit log from the web interface. The audit log REST and GraphQL APIs, Git events, audit log streaming, IP allow lists and SAML SSO require GitHub Enterprise Cloud.