--- title: App logs and how to troubleshoot slug: optimizely-connect-platform/docs/app-logs-and-troubleshooting-ocp2 docTags: createdAt: 2026-07-23T12:37:04.808Z --- To assist in development and debugging, apps can log messages using the App SDK's logger. Log access differs by role. - **Optimizely Support** – Can view all logs for all Optimizely Connect Platform (OCP) apps. - **App developers** – Can view logs produced by their app in the context of OCP accounts they have access to (typically a sandbox account). This includes logs from lifecycle hooks, functions, and jobs, but not global functions. In the OCP CLI, run the `ocp app logs` command to access your logs. - **OCP customers** – Can view logs for apps they have installed to their OCP account. OCP customers access these logs in the **Troubleshooting** tab of the app in the OCP App Directory. :::hint{type="info"} **Note** Logs are intended for debugging and troubleshooting purposes. To provide customer-facing messages in the OCP Activity Log, use [Activity Log notifications](docId\:GyWI81J9JQhanVqmqPlDa). ::: ## Log levels You can log messages with one of the following log levels: - `info` – The default log level for full release and `beta` pre-release app versions. - `debug` – The default log level for `-dev` tagged app versions. - `warn` - `error` To check the current log level for an app installation, run the following command in the OCP CLI: ```shell ocp app get-log-level --trackerId= ``` To change the log level for an app installation, run the following: ```shell ocp app set-log-level --trackerId= ``` :::hint{type="info"} **Note** The change is valid for two hours and then the log level is reset to the default value. ::: Use the `logger` in place of the `console` to ensure that you capture messages properly. However, as a safety measure for uncontrolled usages in dependencies and more, the app runtime captures `console` calls and writes the messages with the following log levels: | Console function | Logger level | | ---------------- | ------------ | | debug | debug | | info | info | | log | info | | warn | warn | | error | error | The logger uses the same mechanism that `console.log` does to inspect objects passed in as arguments. ## Import App SDK `logger` The App SDK exposes the logging feature through the `logger` instance, which you can import as follows: ```typescript import {logger} from '@zaiusinc/app-sdk'; ``` The `logger` instance follows the SDK's `ILogger` interface. ```typescript /** * OCP Logger interface */ export interface ILogger { /** * Write something to the logs at the Debug level * @param args One or more values to log. * Objects are formatted using `util.inspect`, other values are converted to a string. * Multiple values are concatenated with a space between */ debug(...args: any[]): void; /** * Write something to the logs at the Info level * @param args One or more values to log. * Objects are formatted using `util.inspect`, other vaules are converted to a string. * Multiple values are concatenated with a space between */ info(...args: any[]): void; /** * Write something to the logs at the Warning level * @param args One or more values to log. * Objects are formatted using `util.inspect`, other values are converted to a string. * Multiple values are concatenated with a space between */ warn(...args: any[]): void; /** * Write something to the logs at the Error level * @param args One or more values to log. * Objects are formatted using `util.inspect`, other values are converted to a string. * Multiple values are concatenated with a space between */ error(...args: any[]): void; } ``` ### Capture stack traces To capture a stack trace, you must supply the error as a separate argument. ```typescript // This will include the stack trace of `e` if it is an error logger.error('Something went wrong:', e); // This will NOT include the stack trace logger.error(`Something went wrong: ${e}`); ``` ## Access logs in the OCP CLI As a developer, you can use the OCP CLI to access logs produced by your app in the context of OCP accounts you have access to (typically a sandbox account). To access your app logs, run the following: ```shell ocp app logs --appId= --trackerId= ``` By default, the command returns logs from the last 24 hours. You can specify a different time range using the `--from` and `--to` options. As with most CLI commands, use the `-a/--availability` option to query logs from regions other than the default US region. To query logs produced by a job execution, run the following: ```shell ocp app logs --jobId= ``` :::hint{type="info"} **Note** Use the `ocp job list` command to get the job ID. ::: To fetch build logs (produced by the `ocp app prepare` command), run the following: ```shell ocp app logs --buildId= ``` :::hint{type="info"} **Note** Use the `ocp app prepare` command to get the build ID. The experimental `ocp app deploy` command also prints the build ID while it waits for the build. See [Deploy with preview tracks](docId\:gLoc5c6DPRHSfUcBL6bpf). ::: To view more details on other logging options, add the help context (`-h`) to the `ocp app logs` command, like in the following example: ```shell $ ocp app logs -h Active environment: production @optimizely/ocp-cli 1.0.3 (Apache-2.0) Usage: ocp app logs [--tail] [--appId=] [--buildId=] [--appVersion=] [--trackerId=] [--jobId=] [--level=] [--from=] [--to=] [--search=] [--availability=] Flags: --tail Tails the logs Options: --appId The App ID (e.g. my_app). Either App ID or Build ID must be specified. --buildId The ID of the build. Either App ID or Build ID must be specified. Build IDs are printed by 'ocp app prepare' command. --appVersion The app version (e.g. 1.0.0) --trackerId The Tracker ID of the ODP account (required for developers) --jobId Show logs for given execution of a job. Use 'ocp jobs list' command to get the job ID --level Filter app logs by log level. Valid values: INFO, DEBUG, WARN, ERROR --from A start time as an ISO string, an epoch timestamp, or relative string (i.e. "5m" for 5 minutes.) Default: 24h --to A end time as an ISO string, an epoch timestamp, or relative string (i.e. "5m" for 5 minutes) --search String to search for in log messages. Can be specified multiple times. --availability, -a The availability zone that will be targeted (default: us) ```