The Audit log records every sensitive admin action. It’s append-only — you can read it but not edit or delete entries.
What’s logged
| Action | When |
|---|
users.create | New user created |
users.update | User edited |
users.enable / users.disable | Activation toggled |
roles.save | Role created or edited |
timebank.update | Time-bank balance adjusted |
rules.update | Customer rule changed |
smtp.update | SMTP settings saved |
password.reset_requested | User requested password reset |
The table
Path: /app/admin/audit. Shows the most recent 200 entries with:
- When — timestamp, local time
- Actor — user who performed the action (or “System” for automated)
- Action — the action code
- Resource — type + ID of the object affected
- Data — JSON snapshot of what changed
When to check the audit log
- After a dispute — someone claims their balance was wrong. Check who last changed it.
- Security review — look for unexpected actions, unusual hours, unfamiliar actor IDs.
- Training — see how a new admin has been using the system.
- Compliance — show an auditor the history of role changes or SMTP config changes.
What’s not logged
- Normal employee actions (creating a trade, requesting PTO) — those have their own records in their respective tables
- Sign-in events (Supabase Auth handles those separately)
- Data reads (only writes/changes are logged)
Required permission
users.manage — Admin only by default. The log has its own RLS policy that mirrors this.
Don’t rely on the audit log as your only copy of history. It’s easy to forget to backup. For compliance-critical workflows, export the log regularly or replicate the audit table to your org’s SIEM.
