Where Jenkins logs live depends on how it was installed. On Linux packages use journalctl -u jenkins.service. In Docker use docker logs. For security reviews, also turn on HTTP access logs and send everything to a place that outlives the controller, since logs on a compromised host cannot be fully trusted.
Log locations
| Install type | Where to look |
|---|---|
| Linux rpm or deb | journalctl -u jenkins.service, with an optional JENKINS_LOG override through systemctl edit jenkins |
| Windows msi | jenkins.out and jenkins.err under the Jenkins home, unless changed in jenkins.xml |
| macOS | /var/log/jenkins/jenkins.log, unless changed in the plist |
| WAR file | In JENKINS_HOME, or the .jenkins/log folder if that variable is not set |
| Docker | docker logs with the container ID |
What is logged by default
Jenkins uses java.util.logging, which sends messages at INFO and above to standard output. You can add custom log recorders under Manage Jenkins, then Logs, to collect chosen loggers and view them in the web interface. Debug levels come from a logging.properties file passed with a Java system property, and the docs advise against debug levels in production.
HTTP access logs
Access logs are optional. You turn them on through Winstone arguments, and they record client IP, timestamp, request URL, status code and user agent in NCSA combined or common format. For a security review these are often the most useful lines, because they show who called what and when.
What to keep and why
- Controller log. Startup messages, plugin load errors and warnings.
- HTTP access log. Requests, with source addresses.
- Build logs. They may contain secrets if a job printed one, so restrict who can read old builds.
- Configuration history. Changes to jobs and settings, ideally also in version control.
- Authentication events. Whatever your security realm or proxy records.
Choose a retention period that matches your own policy, and write it down. Ship logs off the host to central storage with limited write access.
Reviewing after a suspected issue
- Pull the access log for the period of interest and look for unusual paths, odd user agents and bursts of failed logins.
- Check plugin load messages for unexpected additions.
- Compare job configuration to the last reviewed version.
- Do not rely only on logs held on the same controller.
Try it yourself
The demo shows continuous monitoring, which is the habit of watching changes rather than reading them after an event.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers compliance and evidence automation that can help keep dated records of reviews. There is also a free scan.
Quick check
Does Jenkins log HTTP requests by default?
No. HTTP access logs are optional and enabled through Winstone arguments.
Should I use debug logging in production?
The Jenkins docs advise against debug levels in production.
Sources
Last reviewed: 19 October 2026.
