Audit data retention reference
Audit event retention is managed at the destination layer. Each supported audit destination has independent retention controls and a minimum recommended retention period.
Retention by destination
The following table lists the retention control and minimum recommended retention period for each destination.
| Destination | Retention control | Minimum recommended retention |
|---|---|---|
| Pod standard output | OpenShift node log rotation | 30 days |
| LokiStack | Retention policy in the LokiStack custom resource | 30 days |
| External OpenTelemetry Protocol (OTLP) backend | Retention policy in the external system | 30 days |
Pod standard output
All audit events are written to pod standard output regardless of whether OTLP forwarding is configured. The OpenShift cluster's log rotation configuration and available node disk capacity govern pod log retention. For configuration guidance, see This page is not included, but the link has been rewritten to point to the nearest parent document.About Logging 6.x in the OpenShift documentation.
LokiStack
When you use the OpenShift Logging stack, audit events are stored in LokiStack-backed object storage. Configure a global retention period in the LokiStack custom resource. You are responsible for sizing, retention policies, and lifecycle management of your LokiStack deployment. For configuration and sizing guidance, see This page is not included, but the link has been rewritten to point to the nearest parent document.Installing log storage (LokiStack) and This page is not included, but the link has been rewritten to point to the nearest parent document.LokiStack sizing in the OpenShift documentation.
External OTLP backend
When you forward audit events to an external OTLP-compatible observability backend, configure a minimum retention period in that system.
You can apply different retention policies to business events and CRUD events by filtering on the audit.event_source attribute:
business_event— user actions and agent interactions, emitted by application-level instrumentation. Typically required for compliance and security monitoring.crud_event— database-level change records, generated by database triggers. You can apply a shorter retention period depending on your compliance requirements.
Hard-delete lifecycle and audit data
Automation orchestrator uses a hard-delete model for resource lifecycle management. When you delete a resource, such as a workflow, credential, or user, the platform permanently removes the resource from the database. The deletion is irreversible.
Audit events that reference a deleted resource remain available in your configured destinations until the retention window expires. After the retention window passes, those audit records are permanently removed by the destination's retention policy. No platform mechanism preserves audit records beyond the configured retention period.
If your compliance requirements demand long-term audit records for deleted resources, export the relevant audit data to external persistent storage before the retention window expires. For export instructions, see Export audit data to external storage.
Customer responsibility for long-term retention
Automation orchestrator provides short-term audit data retention only. Data that exceeds the retention window is permanently deleted and cannot be recovered by Red Hat or the platform. You are solely responsible for exporting and archiving audit data to meet your organization's compliance and regulatory retention requirements.
To prevent data loss, establish a recurring export schedule that runs more frequently than your shortest retention window. For example, if your pod log rotation retains 30 days of data, schedule exports at least every 14 days to provide a safety margin.
For detailed export instructions, see Export audit data to external storage.
On-demand purge
Automation orchestrator does not provide CLI or API controls for purging audit data. Manage audit data purge through your OTLP backend's retention configuration or directly in the storage layer (for example, through LokiStack retention policies or object storage lifecycle rules).