Skip to content
Thyme Docs

Logger

ctx.logger is the only way to emit logs that show up in the Console. It is a Logger interface with three levels. The SDK class also buffers entries; local and cloud hosts provide compatible runtime loggers.

Logger class

class Logger {
  info(message: string): void
  warn(message: string): void
  error(message: string): void
  getLogs(): LogEntry[]
  clear(): void
}

Use info, warn, and error in task handlers. getLogs and clear are available on explicitly constructed SDK logger instances; host-provided loggers may only implement the three level methods.

async run(ctx) {
  ctx.logger.info('Fetched price')
  ctx.logger.warn('Price unchanged')
  ctx.logger.error('RPC call failed')
}

createLogger

function createLogger(): Logger

A factory that returns a fresh Logger. The runtime uses it to build the ctx.logger passed to your task; you rarely need to call it yourself.

LogEntry

interface LogEntry {
  type: 'info' | 'warn' | 'error'
  message: string
}

Each call to info / warn / error appends one LogEntry. getLogs() returns the ordered list.

How capture works

The logger behaves differently depending on where the task runs:

  • Cloud (production): each entry is emitted as a line prefixed with __THYME_LOG__ followed by JSON. The runtime parses these lines out of the sandbox output and stores them as the execution's logs, viewable in the Console sidebar.
  • Local (thyme run): a simpler printer writes human-readable [INFO] / [WARN] / [ERROR] lines to your terminal.

Either way, the same ctx.logger.info(...) call works — only the rendering differs. See Local vs Cloud.

Where logs appear

Open an execution in the Console, use the management API, or fetch logs with the CLI:

thyme executions logs EXECUTION_ID --workspace WORKSPACE_ID

The SDK authoring package does not include a management client. See management commands and Monitoring.