Skip to main content
Audit logs record authenticated API requests across your entire organization. Use them to review who called Kernel, which endpoint they called, when the request happened, and how the request completed. Choose the workflow that matches the amount of data you need: Audit logs are ordered newest first. Time windows use an inclusive start and exclusive end: [start, end). A search or export can cover up to 30 days. Split longer periods into multiple time windows. Both workflows are also available from the CLI. For the underlying HTTP API, see search and export in the API reference.

Filter audit logs

The API and SDKs use the same filters for search and export:
  • auth_strategy filters by authentication method, such as api_key, dashboard, or oauth.
  • service filters by the service that emitted the audit event.
  • method returns only requests that use the specified HTTP method.
  • exclude_method omits requests that use any of the specified HTTP methods.
  • search matches path, user ID, email, client IP, and status.
  • search_user_id matches requests from the specified user IDs in addition to any free-text matches.
The API and SDKs include all methods unless you filter. Only the CLI excludes GET by default to reduce noise. Pass --include-get to remove that default exclusion, or pass --method GET to return only GET requests.

Search audit logs

Each API page contains up to 100 events. The SDK pagination helpers request older pages as you iterate.
See the API reference for the full request and response schema.

Export audit logs

The export API returns one chunk per request. Export paging uses a cursor rather than the page token used by search; both are opaque values you pass back unchanged. Repeat requests until X-Has-More is false, passing X-Next-Cursor back as cursor. With the jsonl.gz format, each chunk is an independent gzip member, and appending the members produces a valid gzip file. With jsonl, each chunk contains raw JSON Lines that you can also append. The following minimal examples write all chunks to one file. For a hardened export with checksum verification and retries, use the CLI.
Don’t use these minimal loops for a production export without adding integrity checks and durable cursor storage. For each chunk, buffer the exact response bytes, compare their SHA-256 hash with X-Content-Sha256, write the verified bytes, and then validate the cursor. When X-Has-More is true, require a non-empty X-Next-Cursor that differs from the current cursor. Persist that cursor only after the verified chunk is safely written. You must also retry transient failures. The CLI download command implements this hardened path.
Export chunks contain one JSON object per line. They use the same fields as search results and add event_id, which provides a stable tie-breaker when multiple events share a timestamp. See the API reference for the full request and response schema.