Access operational logs

You can access operational logs to monitor platform component health, diagnose infrastructure errors, and correlate system behavior with workflow and audit event data. Operational logs capture infrastructure-level output from all platform components.

Before you begin

  • You have a role with operational log read permissions in Automation Orchestrator.
  • The oc CLI is installed and authenticated to the OpenShift cluster, if you plan to access pod logs directly.

About this task

Operational logs capture infrastructure-level output from all Automation Orchestrator platform components, including the API server, Temporal worker, agent executor, and OTLP collector proxy. They are written to pod standard output and are distinct from workflow execution traces and audit events.

Procedure

  1. Access operational logs through the web console by navigating to Observability > Operational Logs.

    Use time range, severity level, and component filters to narrow log output.

  2. Stream operational logs directly from pod standard output using the CLI. 
    $ oc logs -f deployment/orchestrator-component-name -n namespace
  3. Configure the runtime log level via the Settings API.

    Replace log-level with a valid log level value. Valid log level value names require SME confirmation for GA — the accepted values in the Settings API runtime setting may differ from the APP_FALLBACK_LOG_LEVEL environment variable values. See the operational log data reference for the currently documented accepted values and confirm with your platform administrator before using in production.

    $ curl -X PATCH -H "Authorization: Bearer token" \
    -H "Content-Type: application/json" \
    -d '{"value": "log-level"}' \
    "https://platform-host/api/v1/settings/logging.log_level"

Results

You have accessed operational logs and can correlate log entries with audit events using correlation identifiers (workflow_instance_id or request_id).