Understand automation orchestrator observability

Automation orchestrator provides three independent observability systems so you can monitor platform health, review system activity, and support Red Hat product improvement.

Three observability systems
Copy link

The three observability systems operate independently of each other. A failure or configuration issue in one system does not affect the others.

Prometheus metrics
You can scrape the local /metrics endpoint with any Prometheus-compatible monitoring system to track request latency, error rates, and workflow execution performance. Prometheus metrics stay within your cluster and require no outbound network access.
Audit event logging (generally available at 2026.8)
Structured JSON event logs that capture all user actions, workflow executions, agent interactions, and security-relevant changes for compliance and security monitoring. Audit events are always emitted to pod standard output for collection by your log aggregation infrastructure (for example, OpenShift Logging with LokiStack, Splunk, or Elasticsearch). When you configure an OpenTelemetry (OTEL) collector endpoint via spec.otel on the AutomationOrchestrator custom resource, audit events are also forwarded to the collector using the OTLP protocol. For the complete description of the dual-channel delivery model, see the related link for audit logging.
Analytics telemetry
Anonymized usage data that automation orchestrator sends to Red Hat for product improvement. This telemetry pipeline operates separately from other Ansible Automation Platform components such as automation controller or automation hub, using different identifiers and transmission paths. No personally identifiable information (PII) is included in telemetry data. Important
Analytics telemetry is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product capabilities, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Analytics telemetry data collected by automation orchestrator
Copy link

Automation orchestrator collects the following categories of telemetry data:

Category What is collected Purpose
Workflow lifecycle Creation, modification, deletion, version creation, version restore, publish, unpublish, and export events Track workflow adoption, design patterns, versioning, and publishing activity
Execution metrics Step timing, success/failure rates, retry counts, timeout events Identify bottlenecks and optimize performance
Approval events Human-in-the-loop approval requests, decisions, and wait times Measure approval turnaround and bottlenecks
API metrics Endpoint response times, status codes, payload sizes, unique callers per period, and feature usage by endpoint Monitor integration health and API adoption
User login Authentication method, identity provider Track authentication patterns
System health Integration health checks, component availability, resource utilization Operational monitoring
Credential usage Credential counts, types, and workflow step references Track credential adoption across workflows
Tool execution Tool namespaced name, execution status, duration Track tool adoption and performance
Large language model (LLM) token usage Token consumption counts per streamed LLM response, model identifiers Track AI-assisted feature costs and usage patterns

API metrics and user login events are not collected by default. Automation orchestrator disables these events to reduce telemetry volume at scale.

All identifiers in telemetry data are anonymized. Workflow and step definitions are represented as SHA-256 hashes rather than the actual content.

Zero-configuration default behavior
Copy link

You do not need to configure any settings, create any resources, or perform any manual steps to activate telemetry. Telemetry collection is enabled by default when automation orchestrator starts.

If your organization requires telemetry to be disabled, you can turn off analytics transmission through the runtime settings.

Telemetry does not affect platform operations
Copy link

Telemetry operations never block or delay your workflows or API responses, even when they fail:

  • If the telemetry endpoint is unreachable, events are retried and then dropped with no impact on platform operations.
  • You do not need to configure firewall rules for telemetry.
  • If outbound access is unavailable, automation orchestrator continues to function normally.

Disconnected environments
Copy link

In disconnected or air-gapped environments, analytics telemetry cannot reach the external endpoint. Events are retried and then dropped when the endpoint remains unreachable, with no impact on platform operations.

Prometheus metrics and audit event logging continue to function normally in disconnected environments because they operate locally within the cluster. Audit events are always available via pod stdout regardless of OTLP collector availability.

Note
Disconnected telemetry export is not available in the Technology Preview release of analytics telemetry.

Review data retention periods
Copy link

Location Retention period
Platform database (audit events) 90 days by default; configurable by administrator
Standard output logs Based on your log aggregation system configuration
External monitoring systems (OTLP destinations) Based on your monitoring system configuration
Red Hat telemetry 90 days for aggregated metrics