Audit Log
Audit Log
Chinaski keeps several trails alongside each other: an audit trail of who changed what, an operational event log, an authentication log, plus build logs and settings history. Admin-only in all cases, so everything here is for site administrators.
The audit trail
Every content mutation (creating, updating, or deleting pages, posts, blocks, documents, categories, media, themes, users, settings, forms, nav items, and more) is recorded with the actor (the logged-in username), the action, the entity type and ID, a short detail line, and a timestamp. Backup operations (restore, push, errors) appear there too.
You can browse it under the audit entry in the admin area. Entries are paginated fifty at a time, and you can search free-text across details and names, or filter by actor, action, entity type, entity ID, or any combination. The page also shows the age of the oldest entry, i.e. how much history you actually have. A CSV export downloads the currently filtered set.
Honest limits: the audit trail records what happened but is not a tamper-proof vault; it’s a plain table in the database. Detail text longer than 4000 characters is truncated.
The event log
Operational messages (warnings, errors, notices) land in the event log. It is shown on the Health page in the admin area, paginated fifty at a time with a level filter: warnings plus errors, or errors only.
Feel free to clear it when it gets noisy: a control on the Health page deletes entries older than 30 days by default, or everything if you choose. Clearing the log is itself recorded in the audit trail, so the cleanup is not invisible.
Authentication log
Every login attempt outcome, success, failure, or blocked (suspended account or IP lockout), is recorded with the username, IP address, and timestamp.
- A per-user view (the login history for any account) lives on each user’s page in the admin area.
- The Health page shows the last 100 authentication entries.
- Repeated failures from one IP trigger escalating lockouts: 60 seconds after 5 consecutive failures, 5 minutes after 10, and 30 minutes after 20. Sustained failure rates raise an alert in the event log.
Retention
Old entries are pruned automatically on a rolling basis, roughly every 15 minutes:
| Trail | Kept |
|---|---|
| Audit trail | newest 50,000 entries |
| Authentication log | newest 10,000 entries |
| Event log | newest 5,000 entries |
| Settings revisions | newest 50 snapshots |
| Build log | newest ~100 completed builds |
Passwords-reset tokens expire after 7 days, and expired user sessions are cleaned up. If you need records to outlive that retention, use the CSV export or an external security log (below) before entries roll off.
Settings history
Every save in settings snapshots all non-secret settings to a revisions history before the write. You can review and restore from the last snapshots on the Settings → History tab. Secret values (SMTP password, webhook secrets, SSO client secret, Turnstile key, Spaces secret) are excluded from snapshots: they are always stored encrypted and never appear in plaintext history.
Structured security log
For forensic purposes Chinaski also emits structured JSON lines for high-signal security events: login success, login failure, login lockout and suspension, SSO login, stale-session clears, registration rate-limiting, and honeypot hits. These go to your system journal (journald on a standard systemd install, journalctl -u chinaski@1 to read them).
If you set the security log destination (Settings → Security) to a file path, those events are additionally appended there: newline-separated JSON, file mode 0600, so a record survives even if the database itself is compromised. Point it at a location excluded from any automated cleanup of the instance directory if that durability matters to you.