Audit records#
The Audit area shows organization-scoped administrative and response actions, including the actor, action, target, request context, and time where recorded. Provider configuration is redacted rather than exposed as plaintext. Normal runtime access cannot edit audit rows; the database also has an immutability trigger.
Export the audit log#
Export, on the Audit page, downloads a date range as JSON Lines or CSV, at most 366 days per download; export longer periods in parts. Rows arrive in time order and are streamed, so a failed read aborts the transfer instead of producing a silently truncated file. CSV cells that a spreadsheet could evaluate as a formula are prefixed with a quote; prefer JSON Lines for machines. Exports are themselves audited.
Passwords, tokens, secrets, credentials and private keys never appear in an export or a stream: values under keys whose names contain password, secret, token, credential, private_key or webhook_url are replaced with [redacted].
Stream to a SIEM#
Each organization can have one stream, under Audit stream on the Audit page. It delivers every record written after the stream is saved; use Export for earlier history.
| Transport | Requirements |
|---|---|
| HTTPS | Signed JSON batches of up to 500 events to an https:// URL on port 443 whose host is in NOTIFICATION_WEBHOOK_HOSTS. Verify X-AckNexa-Signature (HMAC-SHA256 over the timestamp and raw body, with the secret shown once) and reject old timestamps. |
| Syslog | RFC 5424 messages over TLS 1.2 or newer with a verified certificate, default port 6514, to a host listed in AUDIT_SYSLOG_HOSTS. Syslog streams are not signed; TLS is the protection. |
Delivery is at least once: the cursor moves only after the collector accepts a batch, failures are retried with backoff of up to 10 minutes, and one failing batch holds back the ones after it. De-duplicate on the event id. The stream shows the last error and the number of events waiting, and a test action sends one synthetic event without moving the cursor. Private collector addresses also need NOTIFICATION_PRIVATE_CIDRS.
Delivery Health#
Organization administrators use Delivery Health to inspect pending/unpublished events, processing failures, overdue or failed escalation work, exhausted notifications, and quarantined raw events. This view helps diagnose the tenant's processing path; it is not a replacement for independent infrastructure monitoring.
Retry a quarantined event#
- Inspect the reported failure and relevant source payload using authorized operational access.
- Correct the integration, parser, or configuration problem. Do not change the historical payload just to make the record disappear.
- Use the supported dead-letter retry action. It writes an audit record and queues the original event.
- Check processing and incident history. If the underlying issue remains, the event may be quarantined again.
Interpret failures carefully#
- No notification record: inspect routing, active policy targets, schedule coverage, and worker progress.
- Failed notification: check destination, provider configuration, credentials, TLS and network reachability.
- Unknown attempt: the provider may have accepted the request; do not assume no delivery occurred.
- Delayed backlog: inspect database capacity, worker health and broker state before changing application data.
Retention#
Workers prune operational data hourly: expired sessions and login state, outbox rows older than RETENTION_OUTBOX_DAYS (default 7), payloads of processed raw events older than RETENTION_RAW_PAYLOAD_DAYS (default 30; 0 keeps them), and finished delivery-queue rows older than RETENTION_DELIVERY_DAYS (default 30). Pending deliveries are never pruned. Raw event rows, incidents, timelines, notifications and audit events are kept; archive or purge those under your own records policy.
Reports offers basic incident and paging charts; it is not a full analytics suite, and the audit export is not a turnkey compliance product. UI lists are bounded; preserve authoritative history through supported backups.