Skip to content

This tool is not affiliated with, endorsed by or sponsored by Google LLC. Google Workspace, Gmail and Google Drive are trademarks of Google LLC. Other names are trademarks of their respective owners.

Google Workspace Audit Log Retention and Other Limits

What Google Workspace audit logs can't tell you: 6-month retention, lag times, export row caps, CSV vs Reports API fields, license gaps and other blind spots.

Published on 6 min read

TL;DR. Workspace audit logs are good evidence, but they have hard edges. Retention is about six months for the sources an investigation uses. Lag ranges from minutes to hours (days for Takeout completion). Console exports cap at 100,000 rows. CSV exports lose fields the Reports API keeps (network info, nested parameters). Gmail filters aren't in the audit log at all. Some activity isn't logged, depending on the license. Write these limits into every report, and never call an incomplete dataset "clean".

The analyzer lists the sources you didn't provide next to its verdict for exactly this reason. This post is the longer version of that warning.

Retention: six months, and you can't extend it in place

Google's data retention and lag times table gives six months for Admin, User (login), OAuth token, Gmail, Drive, SAML, Takeout and Groups log events. Six months is also the general default for Reports API data. The Reports API reference also limits most applications to 180 days of history per request. Admins can't delete log events or change how long Google keeps them.

In practice:

  • An intrusion discovered late may start before your data. BEC actors can sit in a mailbox for weeks. If the first risky sign-in is older than six months, you will see the persistence but not the initial access.
  • Export at the start of the investigation, not at the end. Every day of delay moves the window.
  • For long-term retention, forward logs somewhere you control. Google documents sharing a subset of Workspace audit logs to Cloud Logging, and exports to BigQuery exist in some editions.

Lag: absence of an event isn't absence of activity

From the same Google table:

SourceDocumented lag
Login events, Admin, Gmail, Drive, SAMLNear real time (couple of minutes)
User account eventsTens of minutes
OAuth token logA couple of hours
GroupsTens of minutes, up to a couple of hours
TakeoutStart events near real time. Completion "up to many days" depending on size

If you export an hour after the phishing click, the OAuth grant may simply not be there yet. Re-export the next day before concluding "no app was authorized".

Export caps and formats

Row caps. Admin console exports are limited to 100,000 rows in standard editions and 30 million with the security investigation tool (Admin log events help). An organization-wide Drive log for a month easily exceeds that. Split by date or user, or use the API.

CSV vs Reports API. The two carry the same events, but not the same detail:

Admin console CSVReports API JSON
Event namesDisplay titles, localized ("Successful login")Stable API names (login_success)
ColumnsOnly those selected in Manage columnsEvery parameter
Network info (ASN, region)Only if the column exists and was selectednetworkInfo on each record
Nested data (Gmail message info, OAuth scope data)Flattened or droppedPreserved
Time formatDepends on console and browser localeRFC 3339 UTC
VolumeCappedPaged, scriptable

Effect on the analyzer. It maps English console titles back to API names, so non-English console exports aren't recognised yet. Country-based rules (new country, impossible travel) only run when records carry a region, which in practice means Reports API input or a country column. There is no GeoIP lookup. When the CSV dates carry no timezone, the tool warns you.

Gmail's 30-day window. For gmail, the Reports API requires startTime and endTime no more than 30 days apart (reference). Scripts that forget this return errors, or partial data if errors are ignored.

Things the audit log doesn't record

  • Gmail filters, delegates, send-as. They are mailbox settings, readable through the Gmail API or the user's settings pages, not audit events. Forwarding is half-covered: the user accounts log records email_forwarding_out_of_domain when it is enabled. See Gmail forwarding rules.
  • Message content. The Gmail log has metadata (subject, sender, recipients, event type), not bodies. Content requires Vault or the mailbox itself, and legal clearance.
  • What an OAuth app did with the data. The token log shows API calls and methods, not the content retrieved.
  • Activity outside Google. Once a file is downloaded or mail is forwarded, the rest happens outside your logs.
  • Actions under some licenses. In 2023, Mitiga reported that Drive activity in users' private drives was not logged for users without a paid Workspace license (Cloud Identity Free). Check what your editions log before you rely on the absence of Drive events.

Heuristics have error bars

Detections are rules, not ground truth:

  • False positives. Travelling staff, VPN and corporate proxy egress on cloud providers, legitimate apps with broad scopes (backup, e-signature, CRM sync), IT creating accounts.
  • False negatives. An attacker using a residential proxy in the victim's country won't trip hosting-ASN or new-country rules. A patient one downloading 15 files every hour stays under a 20-in-15-minutes threshold. Filters using words outside the finance keyword list won't be classed as "hiding finance mail". They are still listed as settings, though.
  • Correlation windows. The chain rules look 14 days ahead on the same account. A cross-account campaign (phish one user, pivot to another) needs a human to connect the dots, using the entity pivot on IPs and apps.

How to write it up

A defensible report says what was examined and what wasn't:

  1. Sources and period, per log (the tool's coverage panel gives you this).
  2. Known gaps: retention edge, missing sources, CSV without network data, license gaps.
  3. Findings with evidence references (event IDs, times, IPs).
  4. Conclusions phrased to match the evidence: "no evidence of X in the examined logs", not "X did not happen".

FAQ

How long does Google Workspace keep audit logs?

Google's data retention table lists six months for the Admin, User (login), OAuth token, Gmail, Drive, SAML, Takeout and Groups log events, and six months as the general default for Reports API data. Admins can't extend it in place. To keep logs longer, export them or forward them to Cloud Logging or BigQuery.

Why don't I see the latest events in the audit log?

Lag. Most sources arrive within minutes, but Google documents a couple of hours for OAuth token events, tens of minutes (up to a couple of hours) for Groups and up to many days for Takeout completion. Export again later before concluding that something did not happen.

Related articles

A fictional business email compromise in Google Workspace, worked from the audit logs: AiTM sign-in, OAuth grant, hidden filter, fraud mail and Drive theft.
Investigate a Google Workspace suspicious login: is_suspicious, hosting ASNs, new countries, impossible travel, failed-login bursts, 2SV and recovery changes.
Step by step: load Google Workspace audit exports into a free in-browser analyzer, read the verdict and evidence, build a timeline, work the remediation list.

This tool is not affiliated with, endorsed by or sponsored by Google LLC. Google Workspace, Gmail and Google Drive are trademarks of Google LLC. Other names are trademarks of their respective owners.