Disabling PostgreSQL Audit Log Storage
If you’re using audit log streams as your primary log destination and don’t need audit logs stored in PostgreSQL, you can disable PostgreSQL audit log storage by setting the following environment variable:Overview
Create Stream
- Navigate to Organization Settings
- Select the Audit Log Streams tab
-
Click Add Log Stream
Select Provider

Input Credentials

Example Providers
Azure
Azure
Create a Data Collection Endpoint
Configure your Data Collection Endpoint by providing an Endpoint Name, Subscription, and a Resource group. Then click Review + Create.
After creation, it may take a few minutes for the Data Collection Endpoint to appear. Once visible, click on it and copy the Logs Ingestion URL. You will need this URL in later steps.
Create a Log Analytics Workspace
Configure your Log Analytics Workspace by providing a Subscription, Resource group, and a Name. Then click Review + Create.
Once the workspace is deployed, click Go to resource to access it.
Create a Custom Log Table
Configure the Custom Log Table: Provide a Table name (e.g., InfisicalLogs), select the Data collection endpoint created in Step 1, and create a new Data collection rule as illustrated in the image below. Then, click Next.
On the Schema and transformation page, you’ll be prompted to upload a Log Sample. Create a .json file with the following content and upload it:Obtain Data Collection Rule Immutable ID

Create Audit Log Stream on Infisical
- Tenant ID: Your Tenant ID
- Client ID: The Client ID of an App Registration
- Client Secret: The Client Secret of an App Registration
- Data Collection Endpoint URL: Obtained from Step 1
- Data Collection Rule Immutable ID: Obtained from Step 4
-
Custom Log Table Name: Defined in Step 3
Better Stack
Better Stack
Connect Source
Once your source is created, take note of the endpoint and Source token for the next step.
Create Audit Log Stream on Infisical

- Fill in the endpoint URL with your Better Stack source endpoint
-
Create a new header with key
Authorizationand set the value asBearer <betterstack-src-token>
Cribl
Cribl
Create Infisical Data Source
Within your Worker Group, navigate to Data > Sources > HTTP and click Add Source.
Configure the Input ID, Port, and Cribl HTTP event API path (e.g., /infisical). Then, generate an Auth Token.You can optionally configure TLS in the TLS Settings tab and add a pipeline in the Pre-Processing tab.
Once you’ve configured the Data Source, click Save and deploy your changes.Create Audit Log Stream on Infisical
- Cribl Stream URL: Your HTTP source endpoint composed of
http://<ingress-address>:<port>/<http-event-api-path>/_bulk - Cribl Stream Token: The authentication token from Step 1
https:// protocol.
Once you’re finished, click Create Log Stream.Datadog
Datadog
Splunk
Splunk
Obtain Splunk Token
Click on HTTP Event Collector.
Click on New Token in the top right.
Provide a name and click Next.
On the next page, click Review and then Submit at the top. On the final page you’ll see your token.Copy the Token Value and your Splunk hostname from the URL to be used for later.
Palo Alto Networks XSIAM
Palo Alto Networks XSIAM
Create an HTTP Log Collector in XSIAM
| Field | Value |
|---|---|
| Name | A descriptive name, e.g. Infisical Audit Logs |
| Vendor | Infisical |
| Product | Audit Logs |
Sumo Logic
Sumo Logic
Create an HTTP Source in Sumo Logic
| Field | Value |
|---|---|
| Name | A descriptive name, e.g. Infisical Audit Logs |
| Source Host | Your Infisical instance URL, e.g. https://app.infisical.com |
| Source Category | A category to query against, e.g. infisical/audit-logs |
Click Save. When prompted to generate the URL, select the Auth Header option (“Use a base URL with separate authentication header”). Sumo Logic will display two values:-
URL: the base endpoint, e.g.
https://endpoint4.collection.sumologic.com/receiver/v1/http -
Header: the authentication header, shown as
x-sumo-token: <token>
Create Audit Log Stream on Infisical
-
HTTP Source Address: The URL from Step 1 (e.g.
https://endpoint4.collection.sumologic.com/receiver/v1/http). -
Auth Token: The token value from the Header field in Step 1 — only the part after
x-sumo-token:, not the prefix. Infisical sends it as thex-sumo-tokenheader.
Delivery Reliability and Failure Handling
Audit log delivery is decoupled from the action that produced the event. When something happens in Infisical, the event is first recorded as an audit log and durably queued for streaming, and only then delivered to your configured destinations in the background. A streaming failure never blocks or rolls back the underlying action, and a temporary outage at your destination does not lose events that were already queued.What happens when an event fails to be pushed to a stream?
If a delivery attempt to your destination fails, the event is not discarded immediately. Instead:- Automatic retries with backoff. The event is retried automatically up to 5 attempts. Retries use exponential backoff with jitter (starting at 30 seconds and capping at roughly 4 minutes between attempts) so a struggling or rate-limiting destination is not hammered.
- Exhaustion. If all 5 attempts fail, the event is dropped from the stream. The drop is surfaced for observability through logs and metrics.
Can I manually retry a failed event?
There is no manual “retry” or “replay” button so far, and retries are not something you trigger yourself. Retrying is fully automatic, as described above: every event is retried up to 5 times with backoff, and crashed or stalled deliveries are automatically recovered by the background sweeper. In practice, transient destination outages recover on their own once the destination is reachable again, with no action required on your side.How can I backfill lost events into my SIEM?
Because streaming is best-effort with bounded retries, your durable source of truth for compliance is Infisical’s own audit log storage, not the stream. To backfill events that were dropped (or that occurred while a stream was misconfigured or disabled), re-ingest them from Infisical’s stored audit logs:- Identify the gap. Use error logs (self-hosted), or the time range of the destination outage, to determine which window of events is missing from your SIEM.
- Export the events from Infisical. Query the missing window from Infisical’s audit logs, filtered by event type, actor, project, and date range:
- In the UI, under Organization Settings → Audit Logs.
- Via the Export Audit Logs API, which returns events in the same structure shown below and can be paginated over the affected time range.
- Re-ingest into your SIEM. Push the exported events into your SIEM using its native ingestion API. The exported fields match the audit log structure below, so the same parsing and transformation rules you already use for the live stream apply to backfilled events.
Delivery Format
Infisical streams audit logs to your destination in batches. Rather than sending one HTTP request per event, Infisical accumulates events and delivers them together, which improves throughput and reduces load on your receiver. For Custom streams, each request is an HTTPPOST with a body containing a JSON array of audit log events:
Example Log Entry
The example below shows a single audit log event. For Custom streams using batch delivery, this object appears as an element inside the JSON array described above.Audit Logs Structure
User Metadata
User Metadata
Identity Metadata
Identity Metadata
actor field is set to platform, scimClient, or unknownUser, the actorMetadata field will be an empty object.get-secrets, delete-secrets, get-secret, create-secret, update-secret, delete-secret, get-workspace-key, authorize-integration, update-integration-auth, unauthorize-integration, create-integration, delete-integration, add-trusted-ip, update-trusted-ip, delete-trusted-ip, create-service-token, delete-service-token, create-identity, update-identity, delete-identity, login-identity-universal-auth, add-identity-universal-auth, update-identity-universal-auth, get-identity-universal-auth, create-identity-universal-auth-client-secret, revoke-identity-universal-auth-client-secret, get-identity-universal-auth-client-secret, create-environment, update-environment, delete-environment, add-workspace-member, remove-workspace-member, create-folder, update-folder, delete-folder, create-webhook, update-webhook-status, delete-webhook, webhook-triggered, get-secret-imports, create-secret-import, update-secret-import, delete-secret-import, update-user-workspace-role, update-user-workspace-denied-permissions, create-certificate-authority, get-certificate-authority, update-certificate-authority, delete-certificate-authority, get-certificate-authority-csr, get-certificate-authority-cert, sign-intermediate, import-certificate-authority-cert, get-certificate-authority-crl, issue-cert, get-cert, delete-cert, revoke-cert, get-cert-body, create-pki-alert, get-pki-alert, update-pki-alert, delete-pki-alert, create-pki-collection, get-pki-collection, update-pki-collection, delete-pki-collection, get-pki-collection-items, add-pki-collection-item, delete-pki-collection-item, org-admin-accessed-project, create-certificate-template, update-certificate-template, delete-certificate-template, get-certificate-template, create-certificate-template-est-config, update-certificate-template-est-config, get-certificate-template-est-config, update-project-slack-config, get-project-slack-config, integration-synced, create-shared-secret, delete-shared-secret, read-shared-secret.createdAt field, as we do not update log entries after they’ve been created.projectId field will only be present if the event occurred at the project level, not the organization level.




