Understand audit event delivery

You can receive audit events from automation orchestrator through pod standard output and, when configured, an OpenTelemetry Protocol (OTLP) compatible observability backend. Business and security audit events stored in the platform database are immutable and tamper-proof.

Events are always written to pod standard output. When OTLP forwarding is enabled, events are also forwarded to your configured observability backend.

Automation orchestrator uses an outbox pattern to maximize delivery reliability. When a platform operation occurs, the application writes an audit record to a transactional outbox table in the same database transaction as the business data change.

business_event and security_event records stored in the platform PostgreSQL database are immutable after the initial write. Records are removed only by the automated retention policy at the end of the configured retention period.

Each audit event carries an audit.event_source field that identifies how it was generated. Automation orchestrator supports three event categories:

  • business_event — emitted by application-level instrumentation. Stored in the platform database and visible in the Audit UI.
  • security_event — emitted for security-relevant operations. Stored in the platform database and visible in the Audit UI.
  • crud_event — generated by database triggers. At GA release, CRUD events are forwarded to the OTLP channel only.
Important

The default maximum dispatch attempt count is 5. A sustained OTLP outage can result in audit event loss. Monitor the audit_outbox row count and alert when it exceeds a threshold.