Audit Log Template for Product Planning

One event per discrete action. A user updating three fields on a profile generates one `user.updated` event with three entries in the `changes` array. Do not generate one event per field. Aggregating changes into a single event makes the log readable and reduces storage volume. The [glossary entry on event-driven architecture](/glossary/prioritization) covers event granularity patterns.

For products under 10,000 customers, build your own. The schema is specific to your domain, and third-party audit log services (WorkOS Audit Log, Pangea) add a per-event cost that scales poorly. At 10,000+ customers with compliance requirements, evaluate managed services to reduce operational burden. The build vs buy decision framework in the [Enterprise Feature Request Template](/templates/enterprise-feature-request-template) applies here.

Each log entry includes an `org_id` field. Queries are always scoped to a single organization. Cross-org queries are restricted to internal support agents and platform operators with elevated permissions. For physical isolation requirements (government, healthcare), consider per-tenant audit log partitions. See the [Multi-Tenant Design Template](/templates/multi-tenant-design-template) for tenancy isolation patterns.

90 days as the default, with 1 year available on paid plans. 90 days covers most incident investigation timelines. Customers on Enterprise plans who need longer retention for their own compliance should get 1-7 years with tiered storage to manage costs. ---