Configure the logger

The **logger** logs information about your experiments to help you with debugging. You can customize where log information is sent and what kind of information is tracked.
In some SDKs, logging functionality is not enabled by default. See [Default logging in each SDK](🔗﻿) below for a list of built-in logger support in each SDK.
To improve your experience setting up the SDK and configuring your production environment, we recommend that you pass in a logger for your Optimizely client. See the code examples below.
﻿
## Log levels
The log levels vary slightly among SDKs but are generally as follows:
**CRITICAL** – Events that cause the app to crash are logged.
**ERROR** – Events that prevent experiments from functioning correctly (for example, invalid datafile in initialization and invalid experiment keys or event keys) are logged. The user can take action to correct.
**WARNING** – Events that do not prevent experiments from functioning correctly, but can have unexpected outcomes (for example, future API deprecation, logger or error handler are not set properly, and nil values from getters) are logged.
**DEBUG** – Any information related to errors that can help us debug the issue (for example, experiment is not running, user is not in experiment, and the bucket value generated by our helper method) are logged.
**INFO** – Events of significance (for example, activate started, activate succeeded, tracking started, and tracking succeeded) are logged. This is helpful in showing the lifecycle of an API call.  
## Default logging in each SDK
**Android** – For the Android SDK, you can use our Android SLF4J [logger](🔗﻿). Logging verbosity can be controlled via the `android-logger.properties` file. This file can be placed in `src/main/resources`. You can also include a copy in `src/release/resources` with different settings for the build you release to the Play Store. Read about [advanced configuration options](🔗﻿).
**iOS** – You can use our default logger and configure `OptimizelyLogLevelInfo`. You can initialize it with any log level and pass it in when creating an `Optimizely` instance. You can also implement your own logger and pass it in the builder when creating an `Optimizely` instance.
**Java** – In the Java SDK, logging functionality is not enabled by default. To improve your experience setting up the SDK and configuring your production environment, we recommend that you include a [SLF4J](🔗﻿) implementation in your dependencies. For the Java SDK, we require the use of an [SLF4J](🔗﻿) implementation.
Warning
Due to a [recently announced security exploit in the Log4J library](🔗﻿), we recommend upgrading to version 2.16.0 or higher as soon as possible if you are using it alongside the SDK. View [Apache's documentation on the Log4j vulnerability](🔗﻿) for more information.
**JavaScript** – By default, the JavaScript SDK uses our [`Logger` implementation](🔗﻿). You can also implement your own logger and pass it into the builder when creating an `Optimizely` instance. It's also possible to configure the log level threshold of the default logger without implementing your own logger. You can do so by passing the constructor an integer `logLevel`, and these are the [possible levels](🔗﻿).
**PHP** – You can use our `Logger` implementation out of the box, available on [GitHub](🔗﻿).
**Python** – You can use our `SimpleLogger` implementation out of the box, available on [GitHub](🔗﻿).
**Ruby** – You can use our `SimpleLogger` implementation out of the box, available on [GitHub](🔗﻿).