Review collected analytics data - Red Hat Ansible Automation Platform

You do not interact with this data directly, and it is not available in the automation orchestrator interface.

This analytics data is separate from the observability features you use to monitor your own environment:

Prometheus metrics provide request latency, error rates, and workflow performance data that you scrape from the /metrics endpoint. See Send metrics to an external monitoring system.
Audit events capture system actions for compliance and debugging, written to standard output for your log aggregation infrastructure. See Audit event reference.

Important:

Telemetry data collection in automation orchestrator 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.

Common context

Every analytics event includes the following context fields. Red Hat uses these fields to correlate events with specific deployments and releases.


Field	Description
`container_image_version`	The container image version running the application (from`APP_CONTAINER_IMAGE_VERSION`).
`entitlement_id`	Installation identifier for event attribution. When you deploy alongside Ansible Automation Platform, this is the subscription identifier. In independent deployments, this is an empty string.
`anonymousId`	Anonymous installation identifier derived from the installation ID and database connection. Used to group events from the same deployment without identifying your organization.

For details about how these identifiers are generated and protected, see How automation orchestrator protects telemetry privacy.

Workflow execution events

Two events track each workflow run: workflow_execution_start when a workflow begins, and workflow_execution_completed when it finishes.

Workflow execution start:


Field	Description
`workflow_execution_id`	Unique workflow execution identifier (UUID v4 format).
`request_id`	Unique request identifier from the originating API request. Matches the`X-Request-Id` header value.
`trigger_type`	How the workflow was started (for example,`manual_trigger`,`scheduled_trigger`,`webhook_trigger`, or`eda_trigger`).
`interface`	Where the request originated:`ui` for the web interface,`api` for external clients (API, CLI, CI/CD).

Workflow execution completed:


Field	Description
`workflow_execution_id`	Unique workflow execution identifier (UUID v4 format). Links to the corresponding start event.
`request_id`	Unique request identifier from the originating API request. Matches the`X-Request-Id` header value.
`status`	Final execution status:`completed`,`completed_with_errors`,`failed`, or`cancelled`.
`duration_ms`	Total workflow execution duration in milliseconds.
`node_count`	Total number of steps that executed within the workflow.
`error_count`	Number of steps that failed during execution.
`error_type`	Categorized error type if the workflow failed. Currently limited to`ActivityExecutionError` or null.
`trigger_type`	How the workflow was started (for example,`manual_trigger`,`scheduled_trigger`,`webhook_trigger`, or`eda_trigger`).
`interface`	Where the request originated:`ui` for the web interface,`api` for external clients (API, CLI, CI/CD).

Step execution events

Each step in a workflow generates a node_execution event when it completes, fails, is skipped, or is canceled.


Field	Description
`workflow_execution_id`	Links to the parent workflow execution (UUID v4 format).
`node_type`	Type of step executed. Values include`manual_trigger`,`scheduled_trigger`,`webhook_trigger`,`eda_trigger`,`condition`,`converge`,`loop`,`switch`,`wait`,`aap_job_template`,`aap_workflow_job_template`,`agentic`,`approval`,`http_request`, and`script`.
`node_hash`	Anonymized identifier for the step definition. Your workflow content and business logic are not included.
`status`	Step execution outcome:`completed`,`failed`,`skipped`, or`canceled`.
`duration_ms`	Step execution duration in milliseconds. This value might be null if timing data is unavailable.
`inbound_nodes`	Array of step hashes that preceded this step in the execution path. This value might be null.
`outbound_nodes`	Array of step hashes that follow this step in the execution path. This value might be null.
`error_type`	Categorized error type if the step failed. Currently limited to`ActivityExecutionError` or null.

Tool execution event

Each tool execution generates a tool_execution event when it reaches a terminal state.


Field	Description
`namespaced_name`	Tool namespaced name in the format`namespace::tool_name` (for example,`mcp::get_greeting`).
`status`	Execution status:`success`,`error`, or`timeout`.
`duration_ms`	Tool execution duration in milliseconds.
`workflow_execution_id`	Parent workflow execution identifier (UUID v4 format). This value is null for tool executions that are not part of a workflow.

API call events

Note:

API call telemetry events are not collected by default. Automation orchestrator disables these events to reduce telemetry volume at scale. API request activity is still captured through audit events, which are always emitted.

Each API request generates a telemetry event with the following fields, excluding health check and metrics endpoints.


Field	Description
`endpoint`	API request path including resource IDs.
`http_method`	HTTP request method:`GET`,`POST`,`PUT`,`PATCH`,`DELETE`,`OPTIONS`, or`HEAD`.
`status_code`	HTTP response status code (100-599).
`response_time_ms`	Response time in milliseconds.
`request_payload_size`	Request body size in bytes, derived from the`Content-Length` header.

Note:

API call events do not capture query strings, request bodies, response bodies, or authorization headers. Only the Content-Length header value is extracted from request headers. All API endpoint paths use underscores as word separators (for example, /api/v1/role_assignments).

For API request audit events, see Audit event reference.

User login event

Note:

User login telemetry events are not collected by default. Automation orchestrator disables these events to reduce telemetry volume at scale. Login activity is still captured through audit events, which are always emitted.

A user_login telemetry event is generated on every successful authentication, whether by password or OpenID Connect (OIDC). To review failed login attempts and security-related authentication events, see Authentication audit events.


Field	Description
`user_id_hash`	Anonymized user identifier. Red Hat cannot use this value to identify individual users.
`amr`	Authentication method used (for example,`["pwd"]` for password,`["fed"]` for OIDC).
`idp`	Identity provider name (for example,`local` for password authentication, or the OIDC provider name).

New user event

A new_user event is generated the first time a user logs in. This event is always collected, regardless of whether user_login events are enabled.


Field	Description
`user_id_hash`	Anonymized user identifier.
`amr`	Authentication method used.
`idp`	Identity provider name.

System analytics event

A periodic snapshot of the current platform state, generated every hour (3600 seconds) by default. Each event contains aggregated counts and statistics, not individual records.

Event name: system_analytics

Workflow counts


Field	Description
`workflows.total`	Total number of workflows.
`workflows.enabled`	Number of enabled workflows.
`workflows.disabled`	Number of disabled workflows.

Execution counts


Field	Description
`executions.total`	Total number of workflow executions.
`executions.completed`	Number of completed executions.
`executions.failed`	Number of failed executions.
`executions.cancelled`	Number of cancelled executions.
`executions.running`	Number of currently running executions.
`executions.pending`	Number of pending executions.
`executions.paused`	Number of paused executions.
`executions.avg_duration_seconds`	Average execution duration in seconds.
`executions.by_trigger_type`	Number of executions grouped by trigger type, such as`manual_trigger`,`scheduled_trigger`, or`eda_trigger`.
`executions.by_interface`	Number of executions grouped by where the request originated:`ui` or`api`.

Credential counts


Field	Description
`credentials.total`	Total number of credentials configured.
`credentials.type`	Credential count per credential type name (key-value map).
`credentials.used_in_nodes`	Number of distinct credentials actively referenced in workflow steps.

Tool counts


Field	Description
`tools.success_count`	All-time count of successful tool executions.
`tools.error_count`	All-time count of failed tool executions.
`tools.timeout_count`	All-time count of timed-out tool executions.
`tools.distinct_tools`	Number of distinct tools that have been executed.
`tools.total_executions`	All-time total tool executions (computed as success + error + timeout).

Model usage

For each large language model (LLM) used, the following fields are included:


Field	Description
`model_usage[].model`	LLM model name.
`model_usage[].total_prompt_tokens`	Total prompt tokens sent to this model.
`model_usage[].total_completion_tokens`	Total completion tokens received from this model.
`model_usage[].total_tokens`	Total tokens (prompt + completion) for this model.
`model_usage[].invocation_count`	Number of invocations for this model.

Configuration


Field	Description
`config.feature_flags_enabled`	List of currently enabled feature flag names.

Unique caller counts


Field	Description
`unique_callers.total`	Total number of unique API callers since the last snapshot. A caller who uses both the web interface and the API is counted once.
`unique_callers.by_principal_type`	Number of unique callers grouped by caller type, such as`user` or`service_account`.
`unique_callers.by_interface`	Number of unique callers grouped by where the request originated:`ui` or`api`.

Feature usage


Field	Description
`feature_usage[].endpoint_group`	API endpoint path (for example,`/api/v1/workflows`).
`feature_usage[].http_method`	HTTP method used for the request.
`feature_usage[].interface`	Where the request originated:`ui` or`api`.
`feature_usage[].request_count`	Number of requests to this endpoint since the last snapshot.

Integration health

Integration health data is emitted as a separate integration_health event at the same interval as the system analytics snapshot. See Integration health event for the full field reference.

Approval events

When a workflow includes a human-in-the-loop approval step, the following events record the request and decision.

Approval requested:


Field	Description
`workflow_execution_id`	Identifier for the workflow run that requested approval.
`approval_node_id`	Activity ID of the approval step in the workflow.

Approval decided:


Field	Description
`workflow_execution_id`	Identifier for the workflow run that requested approval.
`decision`	Decision made:`approved` or`rejected`.
`wait_time_ms`	Time in milliseconds between the approval request and the decision.

Workflow version created event

A workflow_version_created event is generated each time a new version of a workflow is saved.


Field	Description
`workflow_id`	Unique workflow identifier (UUID v4 format).
`version`	Sequential version number within the workflow, starting at 1.

Workflow version restored event

A workflow_version_restored event is generated when a user restores a workflow to a previous version, creating a new draft.


Field	Description
`workflow_id`	Unique workflow identifier (UUID v4 format).
`restored_from_version`	Version number that was restored from.
`new_version`	Version number of the new draft created by the restore operation.

Workflow version published event

A workflow_version_published event is generated when a user publishes a workflow version.


Field	Description
`workflow_id`	Unique workflow identifier (UUID v4 format).
`version`	Version number that was published.
`workflow_name`	Human-readable workflow name.
`project_id`	Project identifier, if the workflow belongs to a project.
`error_type`	Error type if the publish operation failed.`null` on success.

Workflow version unpublished event

A workflow_version_unpublished event is generated when a user unpublishes a workflow.


Field	Description
`workflow_id`	Unique workflow identifier (UUID v4 format).
`version`	Version number that was unpublished.
`workflow_name`	Human-readable workflow name.
`project_id`	Project identifier, if the workflow belongs to a project.
`error_type`	Error type if the unpublish operation failed.`null` on success.

Workflow version exported event

A workflow_version_exported event is generated when a user exports a workflow version.


Field	Description
`workflow_id`	Unique workflow identifier (UUID v4 format).
`version`	Version number that was exported.
`workflow_name`	Human-readable workflow name.

Integration health event

An integration_health event is emitted alongside the system analytics snapshot at the same interval (every hour by default). It is sent as a separate event from system_analytics.


Field	Description
`integrations`	Count of enabled and disabled tool providers, grouped by type.
`identity_providers`	Count of enabled and disabled identity providers, grouped by type.
`credentials`	Count of enabled and disabled credentials, grouped by type, with totals.

LLM token usage events

When AI-assisted features are enabled, automation orchestrator collects the following token usage data per model. This data is aggregated and included in the periodic system analytics event sent to Red Hat.


Field	Description
`model`	LLM model identifier used for the response.
`total_prompt_tokens`	Aggregated prompt tokens for this model.
`total_completion_tokens`	Aggregated completion tokens for this model.
`total_tokens`	Total token count (prompt + completion).
`invocation_count`	Number of invocations using this model.

Workflow error events

If a workflow times out or encounters a retry condition, the following fields are included in the error event.


Field	Description
`workflow_execution_id`	Identifier for the affected workflow run.
`timed_out_component`	What timed out: the workflow or a specific activity.
`configured_timeout_seconds`	The timeout threshold that was exceeded.
`elapsed_time_ms`	How long the operation ran before timing out, in milliseconds.
`activity_id`	The activity that timed out, if the timeout is at the activity level.
`retry_count`	Number of retries attempted.
`error_type`	Name of the exception that caused the error.
`retry_reason`	Reason for the retry, if applicable.

Schema versioning

Telemetry event schemas are defined in the source code and versioned with the application. New fields might be added in future releases, but existing fields are not removed or changed to ensure backward compatibility with the analytics backend.