Forwarding authentik events to a SIEM

Every authentik event is written to container logs at info level, so the server and worker containers are the complete source for a SIEM feed. The server container runs core plus an embedded outpost, and the worker container runs background tasks. Both write to standard output, so a log shipper or the container runtime's logging driver can collect them. PostgreSQL holds all configuration and data except uploaded files, which means the events you see in the admin interface are stored there, but the SIEM does not read from PostgreSQL. Forwarding is a separate path from the database, and retention in PostgreSQL is a separate setting you control. Confirm which containers your collector reads, and confirm that it captures both the server and the worker, since background tasks such as notification delivery run in the worker.

Selected events take a different route. An event matcher policy decides which events qualify, a notification transport defines where they go (locally, by email or to a webhook), and a notification rule connects the two. These sit alongside container logs rather than replacing them, so a rule that sends failed logins to a webhook does not reduce what the container log contains. For Splunk Enterprise, authentik documents forwarding through the HTTP Event Collector, which is a transport choice to plan in advance. Decide whether the SIEM needs the full stream, a filtered stream for alerting, or both, because each choice changes where ingestion and parsing work happens.

On the SIEM side, confirm the ingestion method, the parser or field mapping for authentik's log format, the expected event volume at your tenant size, and how the SIEM handles delivery failures from a webhook. Check with the authentik log forwarding documentation for the current transport options and any transport-specific settings before you build the pipeline. Also confirm where the SIEM must be hosted to meet your data residency and access rules, since that affects whether a managed or self-hosted platform fits. Record these answers in the design, because they determine how much of the pipeline you must test before go-live.

Shorten local event retention in authentik only after the SIEM copy is proven and the SIEM's own retention meets your policy. Local events are the only record until the forwarded copy is verified, so reducing them early can leave a gap that no one notices until an investigation or audit asks for it. Before changing anything, confirm that every event class you rely on arrives in the SIEM with its timestamp, user, source address and event type intact, and that a test event you trigger deliberately (for example, a failed login on a test account) appears there within the window your team considers acceptable.

Local retention also matters for database size. Authentik stores its events in PostgreSQL, so a long local event history grows the database over time, and that growth affects backups and restore times. Check the event retention settings and the cleanup task in the documentation for your exact authentik version, because the setting names and default behavior have changed across releases and should not be copied from an older guide. Confirm the setting and its effect on a staging copy before you change production.

Set the SIEM retention period from your own policy, not from the local setting. Confirm with the SIEM owner how long events are kept, whether the index is replicated or backed up, and who can search them during an incident. Once those answers are written down and a test restore or search of the SIEM data succeeds, reduce local retention in small steps and recheck the forwarding path after each change. Keep a rollback plan in case forwarding stops silently.

Forwarding and alerting answer different questions, and the SIEM does not replace either one. Forwarding copies events out of authentik so your security team can search, correlate and retain them alongside identity data from other systems. Alerting on security events with notification rules decides which events deserve a person's attention within minutes, such as repeated failed logins or configuration changes. Plan both: a notification rule with a transport that reaches your on-call channel, and a complete feed into the SIEM for investigation. Before you remove any local retention, confirm that the SIEM receives the events your alert rules depend on, because a rule that fires inside authentik will not appear in the SIEM unless its events are forwarded too.

Forwarding also says little about whether authentik is running. A SIEM that stops receiving events can mean a dead forwarder, a full queue or a stopped server, and the logs alone will not show which. Keep health monitoring separate: check the server and worker health endpoints, watch the worker, and track the metrics that the monitoring page covers. Set an alert for silence in the SIEM, so that a gap in the event stream is treated as an incident rather than discovered during a review. Confirm with your own team which signal you will use to detect a stopped log shipper, since authentik does not provide that signal on its own.

The next step is to read the sibling pages in this group in order. Start with the alerting page to define the event matchers, transports and rules that must work regardless of the SIEM, then the monitoring page to set health checks and dashboards for the server, worker and outposts. The backup and restore page covers what must survive if the SIEM and local logs are both lost. If you shorten local retention, confirm the restore path and the SIEM's retention before you change anything in production.