Audit trail and system settings
Audit trail
Section titled “Audit trail”/admin/audit reads the audit log. Every admin create, update and delete must
call logAudit(ctx, {...}) — it is a compliance requirement, not a nicety, and
bun run check:audit-coverage fails CI when a mutation is missing one.
When you add a mutation, log it in the same procedure that performs it, after the write succeeds, with enough context to answer “who changed what, from what, to what”.
Reading view_audit_log is owner-tier. The Analytics page shares that
permission.
System pages
Section titled “System pages”| Page | Purpose |
|---|---|
/admin/users |
Roles, via the audited users.updateRoles procedure |
/admin/settings |
Site settings (site-settings router) |
/admin/email-previews |
Transactional email previews |
/admin/audit |
The audit trail |
Health
Section titled “Health”Both apps expose a liveness endpoint that does not touch the database: web
/api/health, API /health. Keep any DB-touching probe off the container
healthcheck — a Neon blip must not be able to mark a container unhealthy and
restart it.