You can view and filter operational system logs to diagnose service errors, resource exhaustion, and connectivity failures. Operational logs capture infrastructure-level data separate from audit events.
Before you begin
- You have a role with operational log read permissions in Automation Orchestrator.
- You are logged in to the Automation Orchestrator web console.
Procedure
- Navigate to the operational log viewer.
In the Automation Orchestrator web console, click Observability > Operational Logs.
The log viewer displays the most recent operational log entries, sorted by timestamp in descending order.
- Filter logs to narrow results to the entries relevant to your investigation.
Use the following filter criteria:
- Time range — set start and end timestamps to scope the view to the period when the issue occurred.
- Severity level — filter by severity (
DEBUG, INFO, WARNING, ERROR, CRITICAL) to isolate errors and warnings.
- Component or service name — filter by the
source_component field to view logs from a specific platform service, such as syntara.execution or syntara.api.
- Keyword search — enter a text string to search across log messages for specific error codes, exception names, or resource identifiers.
- Interpret common log entry patterns to identify the root cause of the issue.
The following patterns appear frequently in operational logs:
- Service errors — entries with severity
ERROR or CRITICAL that include exception stack traces or error codes. These entries indicate a service failure that may require administrator intervention. Check the source_component field to identify the affected service.
- Resource exhaustion warnings — entries with severity
WARNING that reference memory limits, disk space, CPU throttling, or connection pool exhaustion. These entries appear before a service outage and indicate that the platform is approaching capacity limits.
- Connectivity failures — entries that reference connection timeouts, DNS resolution failures, or TLS handshake errors when communicating with external services such as LLM providers, Ansible Automation Platform, or identity providers. Check the target hostname and port in the log message to identify the unreachable service.
- Review the surrounding log entries for context.
After identifying an error or warning, expand the time range slightly to view log entries immediately before and after the event. Preceding entries often reveal the triggering condition, and subsequent entries show whether the platform recovered or the error persisted.
Results
You have identified the relevant operational log entries and diagnosed the root cause of the issue. If the issue requires further investigation, collect the relevant log entries and include them in a support case.
Important:
Operational logs are written to pod standard output and are subject to the OpenShift node log rotation configuration. Logs that exceed the retention period are permanently deleted and cannot be recovered. Operational log retention is independent of audit event retention and is governed by your cluster's log rotation settings, not by OTLP forwarding configuration.