Audit Vault vs the Audit Trail and Audit Log Plugins

Who wrote this, and how

We make Audit Vault. We have tried to be fair, and every fact below links to its source. We compared Audit Trail release 472.vb_51e5934ec50, Audit Log release 1.3 and the current Audit Vault build, on October 28, 2026. We read each plugin's documentation and source code; we didn't run a lab test of all three. Where we say a plugin has no feature, it means we didn't find it in that version's source.

The short answer

Choose Audit Vault if you need to show that the audit log hasn't been edited (a hash chain that the plugin checks itself), or need scheduled exports to cloud storage, SFTP or a SIEM with a local backlog that waits out an outage.
Choose Audit Trail if you want a free plugin that writes to files, syslog or Elasticsearch, and you want script console usage recorded.
Choose Audit Log if you want a free plugin with a log page you can read inside Jenkins and JSON or RFC 5424 syslog output, and your Jenkins is older than the other two plugins support.

Side by side

Numbers in brackets point to the sources at the end of the page.

Audit Vault, Audit Trail and Audit Log compared, as checked on October 28, 2026
Topic	Audit Vault	Audit Trail	Audit Log
Price and license	$99 a month per Jenkins controller, 30-day free trial; a commercial subscription [2]	Free, open source (MIT) [4]	Free, open source (MIT) [8]
Version compared	Current build, source commit fbc6ada [1]	472.vb_51e5934ec50, released October 26, 2026 [7]	1.3, released December 14, 2021 [13]
Minimum Jenkins	2.568.2, Java 21 [1]	2.555.3 [4]	2.222.4 [10]
What it records	Logins, logouts and failed logins; API token use; job and build changes; credential changes and use; plugin, configuration, node and security changes [1]	Web requests that match a URL pattern (by default job and view changes and build actions); build causes; credential use; Groovy script use; logins, failed logins and logouts [3]	Build, node, login and logout, and item lifecycle events, as Apache Log4j Audit events [8]
Where events go	A local database first, then scheduled exports to any of S3 (or S3-compatible), filesystem, SFTP, Azure Blob, Google Cloud Storage, Splunk HEC, syslog over TLS or Datadog [1]	Rolling log files, console, syslog or Elasticsearch [3]	An HTML log in Jenkins' home directory, plus a JSON log file or RFC 5424 syslog [9]
Reading the log in Jenkins	An Audit Vault dashboard with event counts, export status and integrity [1]	No page in Jenkins; read the files or your log tool [6]	An "Audit Logs" page that browses the HTML logs [9]
Tamper evidence	SHA-256 checksum per event, each linked to the previous one; the plugin re-checks the chain in the background [1]	No checksums or hash chain in the source [6]	No checksums or hash chain in the source [12]
If the subscription ends	Capture stops; stored events stay readable and any export backlog still goes out [1]	Nothing to renew [5]	Nothing to renew [11]

When a free plugin is the better fit

Cost matters most. Both are free, and you can read and change their code.
You already run Elasticsearch. Audit Trail sends events to it directly. Audit Vault has no Elasticsearch destination; you would go through S3 or syslog.
You want script console use recorded. Audit Trail logs Groovy script use. Audit Vault has no event for it.
Your Jenkins is older. Audit Vault needs Jenkins 2.568.2 and Java 21. Audit Trail needs 2.555.3 and Audit Log 2.222.4. Even so, an older, unsupported Jenkins is a risk of its own.
You only need a readable record, not proof that it wasn't edited, and your log platform already keeps it safe.

When Audit Vault is worth paying for

An auditor asks how you know the log wasn't changed. Every event carries a checksum linked to the previous one, the plugin re-checks the chain, and each export records the chain head so you can check an archive later.
Events must reach storage outside Jenkins on a schedule. Eight destinations can run side by side, and an event stays in the local database until every enabled destination has confirmed it.
You need credential use and API token logins in the same record as job, build and system changes, sorted by category and severity.

Audit Vault's limits

Capture has limits. Events wait in a 5,000-event queue before they are written; if it fills, new events are dropped and logged. Credential use is recorded at most once per credential and resource every five minutes.
A hash chain shows edits; it doesn't stop them. Someone who can rewrite both the database and every exported copy can hide a change. Keep exports somewhere the controller can't delete from.
It needs a valid license to capture. Without one, no new events are recorded.
It doesn't import history from Audit Trail or Audit Log. Its record starts when you install it.

Details are in the Event Capture, Integrity and Licensing sections of the docs.

Check it yourself

Install the plugin you're considering on a test controller.
Log in, change a job, run a build and use a credential.
Confirm each action shows up where you'll read it, with the right user and time.
Stop the destination for a while, repeat, and see what arrives once it's back.

Next steps

Read the full Audit Vault documentation, or see what the plugin includes and start a free trial on the Audit Vault product page.