Audit Logs

Availability: All plans.

Every action in your Firezone account leaves a record. Firezone captures four audit log streams, and each one answers a different question:

StreamThe question it answers
Change LogsWho changed what in your account configuration, and when?
Session LogsWho connected, from where, and with which device?
API Request LogsWhat did every API client do, request by request?
Flow LogsWhat traffic actually flowed between Clients and Resources?

Log IDs

Every entry is identified by a log_id, a 96-bit identifier written as 24 lowercase hex characters whose first character tells you which stream the entry belongs to:

Streamlog_id starts withExample
Change Logscc0654d20aa1b4a0000000002
Session Logs553f2c8a91b7e4d20a6c19e04
API Request Logsaa7b3e91c4d208f5a6e1b2c3d
Flow Logsff4e8a2c61b09d735e2a48b17

Because the stream is encoded in the identifier itself, a log_id on its own is enough to tell you where an entry came from, and IDs from different streams can never collide.

The rest of the ID depends on the stream. For Change Logs it encodes a timestamp and a per-account counter, which means Change Log IDs always increase and sorting by them reproduces the exact order in which changes were committed. The other three streams fill the remaining bits randomly, so order those by their timestamps instead. The Change Logs page explains what this ordering guarantee is good for.

Subjects and location

When an entry can be traced back to someone, that attribution travels with the entry:

  • Change Logs and Session Logs embed a subject: a snapshot of who performed the action and from where, captured at the moment it happened.
  • API Request Logs record the authenticated actor, API token, and request source directly as fields.

For each of these streams, the portal shows the entry's location alongside it, resolved from the source IP using MaxMind's GeoLite2 City database at the moment the entry is recorded. Because resolution happens at write time, the location reflects where that IP was then, not where it points today.

Flow Logs attribute traffic to an actor, Policy, and Resource, but carry no location data.

Ordering and delivery

Every entry also gets an internal sequence number that Log Sinks use to deliver entries in order. Delivery to a sink is at-least-once, meaning an entry is never skipped but may occasionally arrive twice, so use log_id as your deduplication key.

Retention

Entries in all four streams are kept for 90 days.

Viewing audit logs

Each stream has a dedicated view in the admin portal under Logs:

  • LogsChange Logs
  • LogsSession Logs
  • LogsFlow Logs
  • LogsAPI Request Logs

You can also query them programmatically: the REST API's /logs endpoint lists entries for a given stream with type set to change, session, flow, or api_request, and supports filtering by time range and actor. See the REST API reference for details.

Exporting audit logs

To stream audit logs to your SIEM or log management platform, set up a Log Sink.


Need help? See all support options.

Found a problem with this page? Open an issue
Last updated: July 20, 2026