By default, the Digital.ai Release server writes information, such as: warnings, errors, and log messages to your terminal output and to XL_RELEASE_SERVER_HOME/log/xl-release.log.

In addition, Release writes access logging to XL_RELEASE_SERVER_HOME/log/access.log.

Changing the logging behavior in Digital.ai Release

You can customize the logging behavior in Digital.ai Release. Example: To write log output to a file or to log output from a specific source.

Release uses Logback as logging technology. The Logback configuration is stored in XL_RELEASE_SERVER_HOME/conf/logback.xml.

For more information about the logback.xml file, see Logback documentation.

This is a sample logback.xml file:

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!-- encoders are assigned the type
             ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
                %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n

    <!-- Create a file appender that writes log messages to a file -->
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <pattern>%-4relative [%thread] %-5level %class - %msg%n</pattern>

    <!-- Set logging of classes in com.xebialabs to INFO level -->
    <logger name="com.xebialabs" level="info"/>

    <!-- Set logging of class HttpClient to DEBUG level -->
    <logger name="HttpClient" level="debug"/>

    <!-- Set the logging of all other classes to INFO -->
    <root level="info">
        <!-- Write logging to STDOUT and FILE appenders -->
        <appender-ref ref="STDOUT" />
        <appender-ref ref="FILE" />


Automatically reload the configuration file upon modification

Logback can be configured to scan for changes in its configuration file and reconfigure itself accordingly.

To enable this feature:

  1. Go to and open XL_RELEASE_SERVER_HOME/conf/logback.xml in a text editor.
  2. Set the scan attribute of the <configuration> element to true, and optionally, set the scanPeriod attribute to a period of time.

Note: By default, the configuration file will be scanned every 60 seconds.


<configuration scan="true" scanPeriod="30 seconds" >

For more information, see Logback - auto scan.

The audit log

Important: The audit log is not available between versions 7.5.0 - 8.5.0 of Digital.ai Release.

Release keeps an audit log of each human-initiated event on the server, which complements the auditing provided by the release activity logs (which track activity for each release at a more domain-specific level of granularity).

Some of the events that are logged in the audit trail are:

  • The system is started or stopped
  • An application is imported
  • A CI is created, updated, moved, or deleted
  • A security role is created, updated, or deleted
  • A task is started, cancelled, or aborted
  • Login, logout and failed log in attempts by the user

For each event, the following information is recorded:

  • The user making the request
  • The event timestamp
  • The component producing the event
  • An informational message describing the event

For events involving configuration items (CIs), the CI data submitted as part of the event is logged in XML format.

By default, the audit log is stored in XL_RELEASE_SERVER_HOME/log/audit.log and is rolled over daily.

Enable audit logging

You can enable low-level audit logging by changing the log level of the audit logger in XL_RELEASE_SERVER_HOME/conf/logback.xml:

<logger name="audit" level="off" additivity="false"> <appender-ref ref="AUDIT" /> </logger>

By default, the log stream is stored in XL_RELEASE_SERVER_HOME/log/audit.log. You can change this location, the file rolling policy, and so on by changing the configuration of the AUDIT appender. You can also pipe the log stream to additional sinks (such as syslog) by configuring additional appenders. Refer to the Logback documentation for details.

This is an example of the audit stream in Release pre-7.5.0 with the level of the audit logger set to info:

2014-11-22 11:24:18.764 [audit.system] system - Started
2014-11-22 11:25:18.125 [audit.repository] admin - Created CIs [Configuration/Custom/Configuration1099418]
2014-11-22 11:25:18.274 [audit.repository] admin - CI [Configuration/Custom/Configuration1099418]:
<jenkins.Server id="Configuration/Custom/Configuration1099418" created-by="admin" created-at="2014-11-22T11:25:16.255-0500" last-modified-by="admin" last-modified-at="2014-11-22T11:25:16.255-0500">
  <title>My Jenkins</title>

This is an example in Release 8.6.0 and later:

2019-03-07 14:23:28.412 [audit.repository] admin - Created CI git.Repository[Configuration/Custom/Configuration0f924b19069545c9a6d14d9bfccdc5ac]
2019-03-07 14:23:28.415 [audit.repository] admin - CI [Configuration/Custom/Configuration0f924b19069545c9a6d14d9bfccdc5ac]:
<git.Repository id="Configuration/Custom/Configuration0f924b19069545c9a6d14d9bfccdc5ac">

The access log

You can use the access log to view all HTTP requests received by Release. Access logging provides the following details: URL, the time taken to process, username, the IP address where the request came from, and the response status code. You can use this logging data to analyze the usage of Release and to troubleshoot.

The access log is written to XL_RELEASE_SERVER_HOME/log/access.log.