In Structured Logging for Node.js, I covered how to turn scattered console.log calls into structured, queryable events. That solves the "what happened in the system" problem. It does not solve a different, harder problem: proving what a specific user did to a specific piece of data, at a specific time, in a way that a customer's compliance team or your own support engineer can trust months later.
That is what an audit log is for. This is part of the Full Stack SaaS Masterclass series, and it sits at the point in a product's life where "we should probably log who deleted that" stops being a nice-to-have and starts being a support ticket, a security incident, or a line item in an enterprise contract.
Why audit logs are a different beast than application logs
Application logs answer "why did this request fail" or "how long did this query take." They're written for engineers, they're allowed to be noisy, and losing a percentage of them during an incident is an acceptable tradeoff for keeping the system up.
Audit logs answer "who did this, and can we prove it." The audience is different too: support staff investigating a complaint, a security team responding to an incident, an auditor checking SOC 2 evidence, or a customer's own admin looking at their organization's activity feed. Each reader needs a record that is complete, immutable, and attributable to a real actor.
