GoHighLevel Audit Logs: Track User Changes (2026)
By Dr Priya Jaganathan, GoHighLevel Certified Admin · HL Growth Partner, Australia · Updated 1 October 2026 · 9 min read
GoHighLevel audit logs are the only place in the platform that tells you who changed what, when, and what the value was before they touched it. For an agency with staff in several client sub-accounts, that record is the difference between a calm answer and a guess.
Most agency owners find Audit Logs on a bad day — a pipeline stage has vanished, a custom field is blank across four hundred contacts, a booking confirmation has stopped sending. This post covers what the logs capture, how to run an investigation with them, and what you need to layer on top.
Quick Facts
Confirmed against GoHighLevel's Audit Logs help documentation, 2026.
| Where it lives | Settings → Audit Logs, in Agency view and inside each sub-account |
| What is recorded | Create, Update, Delete and Restore actions across modules including Users, Accounts, Contacts, Opportunities, Websites, Funnels, Stores and Custom Objects |
| Entry detail | The user, module, action type, timestamp and field-level before/after values |
| Who can view | Agency Admins for agency-level logs; Account Admins for sub-account module logs |
| Filtering | By user, module, action type and time range, plus document ID lookup |
| Retention | Entries retained for 60 days, then purged |
| Export | CSV via the Exports tab, up to 500,000 records per export, files available 30 days; the permission sits with Agency Owners, Agency Admins and Account Admins by default |
What HighLevel audit logs actually record — and the gaps nobody warns you about
The log is an event list. Each row names the person, the module, the action, the timestamp and, for updates, the before and after values.
That last detail is the useful one. Knowing a contact was updated is trivia; knowing the lead source field went from Facebook Lead Form to blank at 4.12pm, by name, is an answer.
The modules that are covered
GoHighLevel's documentation lists coverage across Users, Accounts, Contacts, Opportunities, Websites, Funnels, Stores, Custom Objects, Listings and Notification Preferences; practitioner walkthroughs also show Notes, Tasks, Custom Values and Tags in the module filter.
Action types available in the filter are Created, Updated, Deleted and Restored, as set out in the HighLevel Audit Logs documentation. The Restored action matters more than people realise — it is how you confirm a recovery actually happened rather than taking someone's word for it.
The gaps
GoHighLevel's audit log documentation does not describe login or authentication trails. A long-running request for them sits on the HighLevel ideas board, and its comments make clear that agency owners still cannot find a reliable record of when a user signed into a sub-account.
Workflow structure changes are tracked separately, inside each workflow's own version history.
So treat Audit Logs as a record of data and settings changes, not as a complete security log. If a capability is not in your own filter list, do not assume it is being captured quietly in the background.
Who deleted that record? Running the lookup without guesswork
Filter by action type before module. Deletions are rare; updates are not.
- Open the sub-account and go to Settings → Audit Logs
- Set the action filter to Deleted, then narrow the time range to the window described
- Add the module filter once you can see the volume involved
- Use the document ID or name search when you know which record vanished
- Open the detail view on the candidate row for field-level values and the object identifier
Then check the date. Entries are retained for 60 days and then purged, so an incident raised in month four is already gone. That one fact should shape your whole review cadence.
"Our automation stopped" — the investigation order that saves an hour
This is the most common Monday morning message an agency gets, and the audit log is usually not where the answer sits. Work the layers by likelihood.
Start with the workflow itself. Version history records who edited it, the timestamp, and whether the version was a draft or a published build — so a junior who republished a draft shows up immediately.
Only then go to Audit Logs, and look for what changed around the automation: a renamed tag, a deleted custom field, a removed pipeline stage. Workflows rarely break on their own; they break because something they referenced moved.
| What the client reports | Where to look first | What you are looking for |
|---|---|---|
| Automation stopped firing | Workflow version history, then Audit Logs | A republished version; a deleted tag, field or pipeline stage it relied on |
| Contacts missing or wrong | Audit Logs, Contacts module | Delete and Update rows with before/after values |
| Opportunities in the wrong stage | Audit Logs, Opportunities module | Bulk updates by one user in a tight window |
| A funnel page or store changed | Audit Logs, Websites/Funnels/Stores | Create, Update and Delete events on page assets |
| Someone has access they should not | Agency view Audit Logs, Users module | User creation, role changes, deletions |
| Emails stopped reaching a segment | Sub-account Audit Logs, Notification Preferences | Preference and subscription changes, sub-account level only |
Export the filtered log and attach it to the client ticket. That turns a defensive conversation into a factual one.
Pairing audit logs with roles so there is less to investigate
An audit log tells you who did the damage. Permissions decide how much damage was available to do. The second one is cheaper.
Agency-level access should be the exception, not the default. Get your sub-account permissions and user roles right and most of the incidents above stop happening.
The highest-value restriction is bulk delete and bulk update on Contacts and Opportunities for anyone who does not need it daily. Almost every catastrophic log entry I have investigated was a bulk action run by someone who misread their own filter.
The Australian angle
If your agency handles personal information for Australian clients, access control is more than good practice. The OAIC's guidance on APP 11, security of personal information expects reasonable steps against misuse and unauthorised access or modification, and names access controls including logs and audit trails among the measures to consider.
The same guidance expects personal information to be destroyed or de-identified once it is no longer needed. Worth remembering when a client leaves and a sub-account sits dormant for a year.
I am a GoHighLevel admin, not a lawyer, and this is not legal advice — get your obligations reviewed properly.
What to check before and after someone leaves
Offboarding is where audit logs earn their keep, because the 60-day window usually still covers the departure.
Before you remove access, export the logs filtered to that user — afterwards you still have the record even though the account is gone.
- Filter by the departing user across the full available range and export the CSV
- Check the Users module in Agency view for accounts they created or roles they changed
- Review Delete actions in their name while you can still ask them about one
- Remove the user from every sub-account, not just the ones you remember
- Rotate any shared integration credentials they had access to
Client offboarding is a different exercise with its own sequence, covered in our guide to client offboarding and data export.
Building a review cadence that fits inside the retention window
Because entries are purged after 60 days, anything you want to keep must be exported inside that window. The cadence is not optional; it is your retention strategy.
Monthly works for most agencies. On the first business day, export last month's logs for every active sub-account and store them where your team can search them.
Completed export files remain available in the Exports tab for 30 days, so download them to your own storage rather than treating the platform as your archive.
What to actually look at
- Every Delete action across all modules — there should be few, and each should have a reason
- User creation and role changes in Agency view
- Any single user generating an unusual volume of Updates
- Changes to custom fields and custom values, which workflows depend on
Where audit logs stop and what you layer on top
An audit log is evidence, not a recovery tool. Knowing which four hundred contacts were overwritten does not put the old values back.
| Layer | Answers | Known limits |
|---|---|---|
| Audit Logs | Who changed what, when, with before/after values | 60-day retention; no documented login trail; not a workflow change log |
| Workflow version history | Who edited an automation and when; lets you roll back | Up to 10 versions or 30 days, whichever comes first; restore needs Draft status and no enrolled contacts (GoHighLevel Help Docs, 2026) |
| Snapshots and exports | A rebuildable copy of structure and of data | Only as current as your last one; snapshots carry structure, not records |
| Change notes and tickets | Why a change was made | Depends entirely on team discipline |
Treat workflow version history and rollback as your first line for automation incidents, and a disciplined sub-account backup and restore routine as the fallback for what the logs can only describe.
For contact-level questions, the contact timeline often gets you there faster, because it shows the activity in context on the record itself.
Common mistakes to avoid
- Assuming the logs go back further than 60 days, then finding out when a client escalates last quarter
- Searching Agency view for a change made inside a sub-account — the logs are separate, and Notification Preferences entries are sub-account only
- Expecting Audit Logs to show logins — there is no documented login trail, so do not build an access review that depends on one
- Leaving bulk delete and bulk update on for junior staff, then using the log to find out what they did
- Letting CSV exports expire in the Exports tab instead of downloading them to your own storage
- Using the audit log as your backup plan — it records the damage, it does not reverse it
If you want your agency's HighLevel access, permissions and change-tracking set up so nothing gets quietly broken, book a strategy call with the HL Growth Partner team.
Frequently asked questions
How long does GoHighLevel keep audit logs?
GoHighLevel's help documentation states that audit log entries are retained for 60 days and then purged. Anything older is not recoverable from the platform. If you need a longer record, export the logs to CSV monthly and store the files yourself.
Can I see who logged into a sub-account?
GoHighLevel's audit log documentation does not describe a login or authentication trail, and a long-running request for login trails on the HighLevel ideas board still attracts comments from users who cannot locate the feature. Treat sign-in visibility as unconfirmed rather than assuming it is captured. Build your access reviews around user and permission change events instead.
Can I export GoHighLevel audit logs?
Yes. Apply your filters on the Audit Logs tab, click Export, and collect the CSV from the Exports tab once the asynchronous job finishes. GoHighLevel documents a limit of up to 500,000 records per export and states that completed files remain available for 30 days, so download them to your own storage.
Do audit logs show changes made by workflows or the API?
GoHighLevel's documentation focuses on user actions across covered modules and does not clearly document attribution for automation-driven or API-driven changes. Earlier help material described API, Zapier and automation tracking as planned rather than live. Verify what your own account surfaces, and use workflow version history for automation edits.
Can I undo a change from the audit log?
The audit log is a record, not a recovery tool. It shows field-level before and after values so you know what to restore, and Restored appears as an action type, but reversing a change usually means re-entering the data, rolling back a workflow version, or restoring from a snapshot or export.
Who can see audit logs in GoHighLevel?
Agency Admins can view agency-level audit logs under Agency view Settings, and Account Admins can access sub-account module logs. Exporting requires the export audit logs permission, which GoHighLevel documents as held by default by Agency Owners, Agency Admins and Account Admins. Permissions can be customised per user, so review who holds them.
Are audit logs enough for Australian Privacy Act obligations?
Audit logs are one useful control, not a compliance programme. The OAIC's APP 11 guidance expects reasonable steps to protect personal information and names access controls including logs and audit trails among the measures to consider, alongside destroying or de-identifying information no longer needed. This is general information, not legal advice.
Related Articles on HL Growth Partner
Access, roles and ownership
- How user roles protect client data in GoHighLevel
- Transferring a sub-account and handing over ownership
Change control and recovery
- Pushing snapshot updates without breaking live sub-accounts
- Troubleshooting workflow errors step by step
- Why GoHighLevel setups get messy after 90 days
