Logging in Ktor

Estimated reading time: 2 minutes

Ktor uses SLF4J for logging.

SLF4J Providers

If you don’t add a logging provider, you will see the following message when you run your application:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

We can set up logging to remove these warning messages and get a better idea of what is happening with the app adding a provider.

Providers using the Java’s ServiceLoader mechanism, so they are discovered and added automatically without doing anything else by code.

Logback provider

You can use logback, which is the successor of log4j, as SLF4J provider:

Gradle’s build.gradle:

compile "ch.qos.logback:logback-classic:1.2.1"

Mavens’s pom.xml:


Once added, run the app and you should now see the logging messages in the Run pane of IDEA. However, these logging messages are not as helpful as they could be.

Configuring the Logback provider

If the default logging is not enough, you can put a logback.xml or (logback-test.xml that has higher priority) file in your src/main/resources folder to adjust logging if it is not being useful to you. For example:

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
            <pattern>%d{YYYY-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>

    <root level="trace">
        <appender-ref ref="STDOUT"/>

    <logger name="org.eclipse.jetty" level="INFO"/>
    <logger name="io.netty" level="INFO"/>

After adding, if you stop your app, and run it again, after going to localhost:8080 in your browser, now in the IDEA run pane, you should see a log message like:

2017-05-29 23:08:12.926 [nettyCallPool-4-1] TRACE ktor.application - 200 OK: GET - /

To understand how to change the logback.xml configuration file to change the logging, see the logback manual.

Accessing the main logger

The ApplicationEnvironment interface has a log property. You can access it inside an ApplicationCall with call.application.environment.log.