Nov 3, 2025 · Oct 31, 2025 · Oct 31, 2025 · Oct 31, 2025 · Oct 31, 2025 · Nov 3, 2025
diff --git a/docs/admin/security/audit-logs.md b/docs/admin/security/audit-logs.md
 directly against the `audit_logs` table in the database. We advise users to only purge old records (>1yr)
 and in accordance with your compliance requirements.

 ### Maintenance Procedures for the Audit Logs Table

 > [!NOTE]
 > `VACUUM FULL` acquires an exclusive lock on the table, blocking all reads and writes. For more information, see the [PostgreSQL VACUUM documentation](https://www.postgresql.org/docs/current/sql-vacuum.html).

 You may choose to run a `VACUUM` or `VACUUM FULL` operation on the audit logs table to reclaim disk space. If you choose to run the `FULL` operation, consider the following when doing so:

 - **Run during a planned mainteance window** to ensure ample time for the operation to complete and minimize impact to users
 - **Stop all running instances of `coderd`** to prevent connection errors while the table is locked. The actual steps for this will depend on your particular deployment setup. For example, if your `coderd` deployment is running on Kubernetes:

  ```bash
  kubectl scale deployment coder --replicas=0 -n coder
  ```

 - **Terminate lingering connections** before running the `VACUUM` operation to ensure it starts immediately

  ```sql
  SELECT pg_terminate_backend(pg_stat_activity.pid)
  FROM pg_stat_activity
  WHERE pg_stat_activity.datname = 'coder' AND pid <> pg_backend_pid();
  ```

 - **Only `coderd` needs to scale down** - external provisioner daemons, workspace proxies, and workspace agents don't connect to the database directly.

 After the vacuum completes, scale coderd back up:

 ```bash
 kubectl scale deployment coder --replicas= -n coder
 ```

 ### Backup/Archive

 Consider exporting or archiving these records before deletion:
Original file line number	Diff line number	Diff line change
Expand Up		@@ -151,6 +151,36 @@ Should you wish to purge these records, it is safe to do so. This can only be do
		directly against the `audit_logs` table in the database. We advise users to only purge old records (>1yr)
		and in accordance with your compliance requirements.

		### Maintenance Procedures for the Audit Logs Table

		> [!NOTE]
		> `VACUUM FULL` acquires an exclusive lock on the table, blocking all reads and writes. For more information, see the [PostgreSQL VACUUM documentation](https://www.postgresql.org/docs/current/sql-vacuum.html).

		You may choose to run a `VACUUM` or `VACUUM FULL` operation on the audit logs table to reclaim disk space. If you choose to run the `FULL` operation, consider the following when doing so:

		- Run during a planned mainteance window to ensure ample time for the operation to complete and minimize impact to users
		- Stop all running instances of `coderd` to prevent connection errors while the table is locked. The actual steps for this will depend on your particular deployment setup. For example, if your `coderd` deployment is running on Kubernetes:

		```bash
		kubectl scale deployment coder --replicas=0 -n coder
		```

		- Terminate lingering connections before running the `VACUUM` operation to ensure it starts immediately

		```sql
		SELECT pg_terminate_backend(pg_stat_activity.pid)
		FROM pg_stat_activity
		WHERE pg_stat_activity.datname = 'coder' AND pid <> pg_backend_pid();
		```

		- Only `coderd` needs to scale down - external provisioner daemons, workspace proxies, and workspace agents don't connect to the database directly.

		After the vacuum completes, scale coderd back up:

		```bash
		kubectl scale deployment coder --replicas= -n coder
		```

		### Backup/Archive

		Consider exporting or archiving these records before deletion:
Expand Down