Writing and viewing logs for apps, jobs, and functions

Writing logs to standard output and error

In Code Engine, log records emitted by your workload are collected only when they are written to stdout or stderr, following the Twelve‑Factor App guidelines which recommend treating logs as event streams rather than managing log files. See Creating cloud-native applications: 12-factor applications - Factor 11 - Logs.

The platform's logging pipeline automatically captures and processes this output, making it available for analysis and troubleshooting. Log lines written to files in the container's ephemeral file system aren't ingested, persisted, or exposed through the logging interface. As a result, any logs stored on the ephemeral file system are lost when the instance is restarted or terminated and aren't available for operational debugging or root‑cause analysis.

Should I add timestamps to my log lines?

Log records generated by user workloads should avoid embedding their own timestamp information because the Code Engine infrastructure automatically captures and standardizes timestamps. Including application-level timestamps can create inconsistencies across services, especially when workloads run in distributed or containerized environments where system clocks might drift or differ. Relying on the platform’s timestamps ensures uniform time formats, accurate sequencing, and reliable correlation with other system-generated logs, which simplifies troubleshooting, auditing, and observability across the entire deployment.

How do my log levels map to the IBM Cloud Logs severity?

The log level provided in each log record is mapped to IBM Cloud Logs severities as described in Mapping log severities to IBM Cloud Logs severities. In the following sections, you learn more about how the log levels are parsed for unstructured and structured logs and which log level values are supported.

What if my log data is multi-line?

To take advantage of IBM Cloud Logs search and formatting features, change your log formatting as follows.

• If your log lines span multiple lines, change how you format and output your logs so that they're in a single line. Use the JSONL format (see Log formats) for your logs with IBM Cloud Logs.
• Your logs must conform to limits for IBM Cloud Logs.

Examples

Below are simple examples that write an unstructured log line (free‑form text) to standard output.

The examples are published in the Code Engine public sample repository at https://github.com/IBM/CodeEngine/blob/main/logging/README.md.

Node.js (JavaScript)

console.log('User signup succeeded for account abc123');

Python

print("User signup succeeded for account abc123")

Golang

package main

import (
    "fmt"
)

func main() {
    fmt.Println("User signup succeeded for account abc123")
}

Java

package com.ibm.cloud.codeengine.sample;

public class App {
    public static void main(String[] args) {
        System.out.println("User signup succeeded for account abc123");
    }
}

Log level detection

Each log record is scanned for keywords to determine the severity. The severity values, which are evaluated case‑insensitively, are critical, error, warn, info, debug, and verbose.

If a log line begins with a severity keyword in the format LEVEL MESSAGE, Code Engine removes the detected level from the displayed log message so users can focus on the core content while still filtering precisely by severity in the IBM Cloud Logs view. In this case, the extracted severity value is stored in the log record field level. The following case-insensitive severity levels are supported: fatal, error, warn, info, debug, and trace. For instance, in Node.js you might write:

// Unstructured log with level prefix
console.log('ERROR Payment service timeout while creating invoice');

In IBM Cloud Logs, this entry appears with severity Error and the message text "Payment service timeout while creating invoice"; you can then filter by Severity = Error to narrow results. You can also use parsing and severity rules to tailor how levels are extracted and matched for your environment.

Log level detection also works when log lines follow slightly different formats—such as LEVEL: MESSAGE or [LEVEL] MESSAGE. However, in these cases the level keyword is not removed from the log message, even though the severity is still properly classified.

Additionally, the detection logic can infer a severity level when any supported keyword appears anywhere within the message, not just at the beginning. For example, the log line:

The payment workflow encountered an unexpected error during validation

This log line is classified as Error because the word error appears in the message text.

The log level detection does not consider the input stream (stdout or stderr) for log level detection. Therefore, log messages written to standard error (stderr) are evaluated purely on the message text. For example, console.error("Some message") is classified as Info, although it is written to stderr.

For function workloads, the log level is not removed from the displayed log message, even when it is detected at the beginning of the log line in the format LEVEL MESSAGE.

Timestamp parsing and evaluation

Adding timestamps to application log lines is not recommended because Code Engine automatically assigns a normalized timestamp when logs are ingested. If a timestamp is included at the beginning of a log line, the system attempts to parse it. If it matches one of the supported formats, the timestamp is removed from the displayed log message, similar to how log levels are handled. Supported timestamp formats include:

• 2026-02-08T20:30:45.123
• 2026-02-08T20:30:45.123Z
• 2026-02-08T21:03:45.123456Z
• 2026-02-08T21:03:45.123456789Z
• 2026-02-08 21:03:45.123Z
• 2026-02-08 20:30:45.123

When a log line contains both a timestamp and a log level at the beginning (for example, TIMESTAMP LEVEL MESSAGE), the pipeline evaluates both fields. If both match supported patterns, they are each classified appropriately and removed from the rendered log message, leaving only the message body for easier reading and filtering. For example, the following formats are successfully parsed:

• 2026-02-08T21:03:45.123456789Z ERROR Payment service timeout
• 2026-02-08 20:30:45.123 INFO Starting billing workflow

In cases where a timestamp appears but does not match the supported formats, it remains part of the log line and is treated as regular text, but the rest of the message is still processed normally.

For function workloads, timestamps are not parsed, evaluated, or removed from log messages. Any timestamp included in function logs remains part of the displayed message.

Multi-line support

Code Engine supports multi‑line log entries. However, when you emit logs, you must ensure that newline characters (\n) are properly encoded (\\n) so the logging pipeline can correctly process and render multi‑line messages. For example, in Node.js, you can produce a multi‑line log entry like this:

console.log("Starting billing workflow...\\nStep 1: Validating input...\\nStep 2: Processing payment...");

Logging errors

If your workload emits multi‑line error stack traces, use the structured JSON log format instead of unstructured console output. Structured logs preserve multi‑line fields reliably and ensure that stack traces are grouped into a single log record, which is covered in the section Structured logs.

For example, the following log message is classified as Error because the keyword "error" appears in the log message. However, the stack trace that is provided by the err object is rendered in multiple log lines.

try {
  throw new Error("boom!");
} catch (err) {
  console.error("An error occurred", err);
}

Examples

The following are minimal structured‑logging examples for each language and runtime that emit a single JSON with the log level in the level field and the log message in the message field.

The examples are published in the Code Engine public sample repository at https://github.com/IBM/CodeEngine/blob/main/logging/README.md.

Node.js (winston)

import winston from "winston";
const { combine, json } = winston.format;

// Create a custom logger
const logger = winston.createLogger({
  level: 'info',
  transports: [new winston.transports.Console()],
  format: combine(json())
});

// Usage
logger.info("User signup succeeded")
logger.error("Payment service timeout")

Python (Loguru)

from loguru import logger
import sys
import json
import traceback

# Define a custom JSON sink
def json_sink(message):
    record = message.record

    # Base fields: level + message, no timestamp
    payload = {
        "level": record["level"].name,   # e.g., "INFO"
        "message": record["message"],    # rendered message
    }

    # Merge in any bound extra fields as top-level keys
    # (skip reserved keys to avoid accidental overwrite)
    for k, v in record["extra"].items():
        if k not in ("level", "message", "stack"):
            payload[k] = v

    # If an exception is attached, render full stack trace into "stack"
    exc = record["exception"]
    if exc:
        # exc.type, exc.value, exc.traceback are available from Loguru
        stack_text = "".join(traceback.format_exception(exc.type, exc.value, exc.traceback))
        payload["stack"] = stack_text

    # Emit a single JSON line
    sys.stdout.write(json.dumps(payload, ensure_ascii=False) + "\n")
    sys.stdout.flush()


# Remove default handler (which includes timestamp, etc.) and add our custom sink
logger.remove()
logger.add(json_sink, level="DEBUG")  # lowest level you want to capture

# Usage
logger.info("User signup succeeded")
logger.error("Payment service timeout")

Golang (slog)

package main

import (
    "log/slog"
    "os"
)

func main() {
    handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        // Remove time and rename msg->message
        ReplaceAttr: func(groups []string, attr slog.Attr) slog.Attr {
            // Drop the time attribute
            if attr.Key == slog.TimeKey {
                return slog.Attr{} // empty => removed
            }
            // Rename msg to message
            if attr.Key == slog.MessageKey {
                return slog.String("message", attr.Value.String())
            }
            return attr
        },
    })
    logger := slog.New(handler)

    // Usage
    logger.Info("User signup succeeded")
    logger.Error("Payment service timeout")
}

Java (SLF4J and Logback with logstash-logback-encoder)

src/main/resources/logback.xml:

<configuration>
    <appender name="jsonConsoleAppender" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <timeZone>UTC</timeZone>
            <fieldNames>
                <timestamp>[ignore]</timestamp>
                <logger>[ignore]</logger>
                <version>[ignore]</version>
                <levelValue>[ignore]</levelValue>
                <threadName>[ignore]</threadName>
            </fieldNames>
        </encoder>
    </appender>

    <root level="DEBUG">
        <appender-ref ref="jsonConsoleAppender" />
    </root>
</configuration>

src/main/java/com/ibm/cloud/codeengine/sample/App.java:

package com.ibm.cloud.codeengine.sample;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class App {
  private static final Logger logger = LoggerFactory.getLogger(App.class);

  public static void main(String[] args) {
    logger.info("User signup succeeded");
    logger.error("Payment service timeout");
  }
}

Log level detection

Each log record is scanned for keywords to determine the severity. The severity values, which are evaluated case‑insensitively, are critical, error, warn, info, debug, and verbose.

When you use structured logs, Code Engine automatically detects the log level when it is provided in one of the following fields: level, severity, or logLevel. The value in these fields is case‑insensitive, meaning entries such as error, ERROR, or Error all map to the same severity. The following case-insensitive severity levels are supported: critical, error, warn, info, debug, and verbose. When a supported field is present and contains one of these values, the log level is extracted, normalized, and used for filtering and categorization within the Logs UI. For example, the following structured log lines are all properly interpreted with level Error:

{ "level": "error", "message": "Payment service timeout" }
{ "severity": "ERROR", "message": "Failed to connect to database" }
{ "logLevel": "eRrOr", "message": "Workflow aborted" }

Regardless of the capitalization or the specific field value used, the platform correctly identifies the log level and applies it for filtering, grouping, and analytics across your structured log data.

Timestamp evaluation

For structured logs, custom timestamps are not parsed or evaluated. Any timestamp field you provide is treated purely as payload data, while the platform always applies its own ingestion timestamp for ordering and filtering.

In below example, "timestamp" value is preserved but ignored for log timing.

{ "level": "INFO", "message": "Processing started", "timestamp": "2026-02-08T20:30:45.123Z" }

Adding additional context information

You can enrich structured logs with custom fields (for example, requestId, userId, or domain‑specific metadata). The following are minimal examples for each stack used earlier.

Keep custom fields concise and stable (for example, IDs, codes, or small enums) to maximize filterability and minimize cardinality in your logging instance.

Node.js (winston)

logger.debug("A structured log entry that contains an extra key", {
  extra_key: "extra_value",
});

Python (Loguru)

logger.bind(extra_key="extra_value").debug("A structured log entry that contains an extra key")

Golang (slog)

logger.Debug("A structured log entry that contains an extra key",
  slog.String("extra_key", "extra_value"),
)

Java (SLF4J and Logback with logstash-logback-encoder)

logger.atDebug().addKeyValue("extra_key", "extra_value")
                .log("A structured log entry that contains an extra key");

Logging errors

To capture both the error message and its stack trace in structured logs, emit a JSON record that includes your standard fields (level, message) plus a stack (or similar) field.

Node.js (winston)

// Error logging
try {
  throw new Error("boom!");
} catch (err) {
  // The error stack trace is rendered in a single log message (see field stack)
  logger.error("An error occurred", err);
}

Python (Loguru)

try:
  raise RuntimeError("boom!")
except Exception:
  # logger.exception() automatically attaches the current exception info
  logger.exception("An error occurred")

Golang (slog)

err := errors.New("boom!")
logger.Error("An error occurred",
    slog.Any("err", err),
    // The error stack trace is rendered in a single log message (see field stack)
    slog.String("stack", string(debug.Stack())),
)

Java (SLF4J and Logback with logstash-logback-encoder)

try {
    throw new RuntimeException("boom!");
} catch (Exception e) {
    logger.atError()
            .setCause(e) // The error stack trace is rendered in a single log message (see field stack_trace)
            .log("An error occurred");
}

Function workloads handle multi-line logs, but each newline character results in a separate log entry. When logging stack traces with structured logging frameworks, you might need to manually escape newline characters to ensure they are rendered properly as a single log entry.

Can I apply filters on IBM Cloud Logs data?

You can modify and scope the filter to display log data at a specific level or a more granular level to a specific application revision, job run, or build run from the IBM Cloud Logs page, based on your needs.

• If message.serviceName:"codeengine" is set, then only Code Engine logs are displayed.

• If label.Project:'<project_name>' is set, then only logs from a specific project are displayed.

• If message._app:'<your_component_name>' is set, then only logs from the specified component (application, job, or build) are displayed. If your Code Engine components share the same name, the filter includes logs from these components. For example,

  • The filter message.serviceName:"codeengine" AND message._app:"myapp" scopes the logs to the myapp application level.
  • The filter message.serviceName:"codeengine" AND message._app:"myapp\-00002" scopes the logs to the myapp-0002 application revision level.
  • The filter message.serviceName:"codeengine" AND message._app:"myjob" scopes the logs to the specific myjob job level.
  • The filter message.serviceName:"codeengine" AND message._app:"myjob\-jobrun\-t6m7l" scopes the logs to the specific myjob-jobrun-t6m7l job run level.
  • The filter message.serviceName:"codeengine" AND message._app:"mybuild" scopes the logs to the specific mybuild build level.
  • The filter message.serviceName:"codeengine" AND message._app:"mybuild\-run\-121212" scopes the logs to the specific mybuild-run-121212 build run level.

For more information about configuring and starting logging in the console, see viewing app, job, or function logs from the console.