---
title: Audit Logs
---

Audit logs provide comprehensive tracking of all user actions and entity changes in InfraKitchen, enabling compliance, security monitoring, and operational transparency.

## Overview
InfraKitchen automatically records audit logs for every significant action performed on entities within the system. These logs capture who performed an action, what was changed, and when it occurred, providing a complete audit trail for compliance and troubleshooting purposes.

:::info[Automatic Logging]
Audit logs are created automatically whenever a user interacts with entities—you don't need to configure anything. All actions are tracked by default.
:::

## Audit Log Structure

Each audit log entry contains the following information:

| Field | Description |
|-------|-------------|
| **Time** | When the action was performed (timestamp) |
| **User** | The user who performed the action (display name and ID) |
| **Event** | The action type (e.g., create, update, execute, approve) |
| **Entity ID** | The unique identifier of the affected entity |
| **Model** | The entity type (e.g., resource, template, integration) |
| **Audit Log ID** | Unique identifier for the audit log entry itself |

## Deleted Entities

Deleting a resource removes its record from InfraKitchen, but the audit trail must still show *what* was deleted—not just an opaque ID.

To make this possible, InfraKitchen stores a **snapshot** of the entity as the audit log entry's `metadata` at the moment the delete is recorded. `metadata` is a JSON object whose content depends on the action; for `delete` it is the entity snapshot. The snapshot captures identifying and contextual details such as name, state, status, description, labels, revision number, and the related template, source code version, project, and workspace.

The **Entity** column keeps rendering the entity name after deletion by falling back to this snapshot. Since the entity no longer exists, the name is not a link.

:::note[Sensitive values]
Snapshots never include variable values. Only variable *names* are stored, so secrets and sensitive inputs are not persisted into the audit trail.
:::

Snapshots are captured going forward. Entries recorded before this behavior existed have no snapshot and show only the entity type.

## Viewing Audit Logs

### Global Audit Logs

Navigate to **Administration** → **Audit Log** in the sidebar to view the complete audit trail of all actions. Use the dropdown to filter by event type, and sort by any column (time, user, event).

### Entity-Specific Audit Logs

To view audit logs for a specific entity, open it and click the <kbd>Activity</kbd> button, then switch to the **Audit** tab to see all actions performed on that entity.

### Event Types

Global audit logs can be filtered by event types:

| Event | Description |
|-------|-------------|
| **create** | Entity was created |
| **update** | Entity was modified |
| **delete** | Entity was deleted |
| **execute** | Action was executed |
| **approve** | Resource change was approved |
| **reject** | Resource change was rejected |
| **destroy** | Resource infrastructure was destroyed |
| **recreate** | Destroyed/rejected resource was recreated |
| **retry** | Failed operation was retried |
| **sync** | Entity was synchronized |
| **enable** | Entity was enabled |
| **disable** | Entity was disabled |
| **dryrun** | Plan operation was performed |

## Correlation with Execution Logs

Audit logs are automatically correlated with execution logs through a `audit_log_id`:

1. When an action creates an audit log, the audit log ID is stored as `audit_log_id`
2. Any execution logs generated during that action reference the same `audit_log_id`
3. This allows you to see both **what was done** (audit) and **how it was done** (execution logs)

Example flow:

```
User executes resource
  └─> Audit log created (action: "execute", audit_log_id: abc-123)
       └─> Execution begins
            └─> Logs written with audit_log_id: abc-123
```

This enables complete traceability from user action to system execution.