Audit logs record who did what, when, from where, and with what outcome across your Formbricks instance.


Benefits of audit logging

  • Compliance readiness — Many regulatory frameworks such as GDPR and SOC 2 require immutable records of user activity.
  • Security investigation support — Audit logs provide clear visibility into user and system actions, helping teams respond quickly and confidently during security incidents.
  • Operational accountability — Track changes across the system to answer common questions like “who modified this?” or “when was this deleted?”.

Enabling audit logging

  1. Set the following environment variables in your deployment (Docker Compose, Kubernetes, etc.):
.env
# --- Audit logging ---
AUDIT_LOG_ENABLED=1
AUDIT_LOG_GET_USER_IP=1                        # set to 1 to include user IP address in audit logs, 0 to omit (default: 0)
  1. Redeploy your containers.
  2. Confirm you can see audit logs in the output of your containers.

Audit logs are printed to stdout as JSON Lines format, making them easily accessible through your container logs or log aggregation systems.


Understanding the log format

Audit logs are JSON Lines (one JSON object per line). A typical entry looks like this:

{"level":"audit","time":1749207302158,"pid":20023,"hostname":"Victors-MacBook-Pro.local","name":"formbricks","actor":{"id":"cm90t4t7l0000vrws5hpo5ta5","type":"api"},"action":"created","target":{"id":"cmbkov4dn0000vrg72i7oznqv","type":"webhook"},"timestamp":"2025-06-06T10:55:02.145Z","organizationId":"cm8zovtbm0001vr3efa4n03ms","status":"success","ipAddress":"unknown","apiUrl":"http://localhost:3000/api/v1/webhooks","changes":{"id":"cmbkov4dn0000vrg72i7oznqv","name":"********","createdAt":"2025-06-06T10:55:02.123Z","updatedAt":"2025-06-06T10:55:02.123Z","url":"https://eoy8o887lmsqmhz.m.pipedream.net","source":"user","environmentId":"cm8zowv0b0009vr3ec56w2qf3","triggers":["responseCreated","responseUpdated","responseFinished"],"surveyIds":[]}}

Key fields:

FieldDescription
levelLog level, always "audit" for audit events
timeUnix timestamp in milliseconds
pidProcess ID of the logging instance
hostnameHostname of the server generating the log
nameApplication name, typically "formbricks"
timestampISO‑8601 time of the action
actorUser or API key responsible (object with id and type)
actionConstant verb‑noun string (survey.updated, login.failed, …)
targetThe resource affected (object with id and type)
statussuccess or failure
organizationIdOrganization identifier where the action occurred
ipAddressUser IP address, present only if AUDIT_LOG_GET_USER_IP=1, otherwise "unknown"
apiUrl(Optional) API endpoint URL if the logs was generated through an API call
eventId(Optional) Available on error logs. You can use it to refer to the system log with this eventId for more details on the error
changes(Optional) Only the fields that actually changed (sensitive values redacted)

Centralized logging and compliance

Formbricks audit logs are designed to work with modern centralized logging architectures:

  • Stdout delivery: Logs are written to stdout for immediate collection by log forwarding agents
  • Centralized integrity: Log integrity and immutability are handled by your centralized logging platform (ELK Stack, Splunk, CloudWatch, etc.)
  • Platform-level security: Access controls and tamper detection are provided by your logging infrastructure
  • SOC2 compliance: Most SOC2 auditors accept centralized logging without application-level integrity mechanisms

Additional details

  • Redacted secrets: Sensitive fields (e‑mails, access tokens, passwords…) are replaced with "********" before being written.
  • Failure events count: Both successful and failed operations are logged.
  • Single source of truth: The same logs power the Formbricks UI and API endpoints.
  • Scope limitation: For now, only events triggered inside the Formbricks application are audited. This means:
    • Embed and Link Surveys are not included in the audit logs.
    • Survey responses created via the client API or client-side SDKs are not audited.