Zendesk Audit Logs
Somebody changed a trigger and half a day of tickets went to the wrong group. Zendesk audit logs are how you find out who, and how you stop guessing.
Where Zendesk audit logs live, and what they aren't
The account audit log sits in Admin Center, in the security and account area, and availability depends on your plan. It's a higher-tier feature rather than something every account gets, so check yours before you write a process that depends on it.
It records administrative and configuration change at the account level. It is not the ticket audit trail, which is a separate and always-present thing: every ticket carries its own event history showing field changes, comments and who made them, visible on the ticket itself.
Confusing the two produces bad promises. An auditor asking about access to a customer record wants something different from a list of trigger edits, and you don't want to discover that mid-review.
There's a third thing people mean by audit log as well, which is their own change notes. Zendesk doesn't provide those and it isn't going to. If you want a record of intent alongside the record of events, somebody has to write it.
What gets recorded
What you never get is why. The log tells you a trigger was edited at 16:52 on a Friday. It will never tell you the person was fixing something urgent, which is why your own change notes matter, as covered in the admin role guide.
It also isn't a record of every ticket an agent opened. Don't promise an auditor that it is. If you need access-level visibility of that kind, check what the advanced privacy add-on offers rather than assuming the audit log already covers it.
Retention, and why you should export anyway
The log doesn't keep everything forever. Retention is finite and it depends on plan and product decisions that get revised, so look it up in the current Zendesk documentation rather than trusting a number written in an article.
The operational conclusion is the same whatever the number turns out to be. If you might ever need it, export it. A monthly pull into your own storage or into whatever log platform you already run costs almost nothing and removes the question permanently.
The moment you need an old entry is reliably the moment you discover the window closed last week.
Getting it out through the API
Zendesk exposes audit log entries through its REST API, so you can pull them on a schedule instead of paging through a filter by hand.
The shape of the job is boring and that is the point. A scheduled task filtered by creation date, paging through results, writing each batch into a warehouse or a SIEM. Run it under a dedicated service account with its own token rather than under a person, so it survives that person leaving.
The endpoint sits under the standard v2 API alongside everything else, and the current API reference is the only place worth taking the exact path and filter parameters from, because parameters get added. There is background on authentication and paging in the Zendesk API guide.
Using it in an incident review
Fix the thing first. Investigate second. Reviews done while customers are still affected produce worse answers.
Then set the window generously. Start from when the symptom first appeared and go back further than feels necessary, because configuration changes often surface hours or days after somebody made them.
Filter by change type before you filter by person. Starting from a suspect produces a story you then go and confirm, which isn't the same as finding out what happened.
Correlate the two layers. The account log tells you a trigger changed; the ticket event history tells you what that change actually did to individual tickets. You need both to size the damage.
Write the timeline with timestamps and note the timezone, because half the confusion in any review is somebody reading UTC as local. Then finish by writing the fix as a change to process rather than a note about a person. The log is a diagnostic tool. It shouldn't become a disciplinary one.
Frequently asked questions
Is the audit log the same as the activity log?
No. The Zendesk audit trail records configuration changes, who made them and when. The Zendesk activity log an agent sees is their own notification feed, which is a different thing entirely.
Which Zendesk plans include the audit log?
It sits on higher tiers rather than being available everywhere, and the boundary has moved over time. Confirm it for your own plan before building a compliance process around it.
How long does Zendesk keep audit log entries?
Retention is finite and depends on plan and product decisions that change, so check the current documentation. Whatever the answer, export the log if you need history beyond it.
Does the audit log show which tickets an agent viewed?
Not in the way people hope. The account log covers configuration and administrative events. Access-level visibility of ticket views is a different capability, so ask specifically before you commit to it.
Can I export the Zendesk audit log?
Yes, through the REST API. A scheduled pull into your own storage is the only reliable way to keep entries beyond the platform retention window.
Is the ticket event history the same as the audit log?
No. Every ticket has its own event history showing field changes and comments. The audit log is account-wide and covers configuration, and neither one replaces the other.
Two tickets, two histories
When the same problem arrives twice, the story of it splits across two audit trails. Merging duplicates keeps the record of a conversation in one place.
Start free trial14-day free trial. No credit card required.