Why it matters
An audit log records meaningful product actions, their actor, target, time and outcome. It is a customer feature as well as an operational tool, so its event names and retention rules deserve deliberate design.
An audit log answers who changed a customer-visible state, what changed and when. It is different from application debugging logs: customers need stable, comprehensible events and reliable retention.
Decisions to make
- Choose which actions are useful to a customer, including refusals and administrative changes.
- Define retention, export and visibility for each account.
- Record machine actors and delegated actions alongside human users.
- Choose which actions are security relevant and which are merely operational noise.
- Decide retention, export access and whether administrators can see every actor.
Build checklist
- Emit structured events from the authoritative write path.
- Include actor, organization, action, target, time and outcome.
- Test that sensitive values are redacted and that tenant boundaries hold on queries.
- Record actor, organization, action, target and outcome as structured fields.
- Test that failed and denied actions are captured where they matter.
Common mistakes
- Presenting application logs as a complete audit history.
- Logging secrets or personal data into a long-lived audit stream.
- Creating event names from UI labels that change with a redesign.
Tools & references
3 starting points to compare or study. Check fit, maintenance, terms and current capabilities before choosing one.
