Our app needs an audit view for administrators to see employee create, update, and delete actions. IT and developers also need access to security events like logins and password resets, though that view doesn't have to be in the app.
Would you use separate tables, combine everything in one view, or send some logs to an external service?
I'd separate them based on who needs them and what they contain. Audit events can have a stable schema tied to the acting user and affected record. Security events have a different shape and may need different access and retention rules. Exceptions can go to an error tracking service such as Sentry.
You can still offer one interface for audit and security events if that's useful. Combining them in the UI doesn't require forcing them into the same table.
Treat the audit trail as a product feature, not just debug output. Make it append only, keep its schema stable, and restrict who can read it. Include the actor, affected record, action, and time so administrators can understand what happened.
For the admin screen, start with bounded filters such as date and user. Paginate results rather than allowing an unrestricted query over the whole table. Large exports can run as background jobs.
Consider keeping security and error logs outside the app database. If a deployment damages or removes data there, you don't want it taking all the diagnostic evidence with it too.
A shared request ID across audit, security, and error events can help trace an incident without combining their schemas. You still need to control access separately because the audiences and sensitivity can differ.
Set retention separately rather than picking one number for everything. One possible starting point is three years for audit events, one year for security events, and 90 days for errors. Check those choices against your organization's requirements and what each group actually needs before making them defaults.
Answers are reviewed before publication.
Kellin.4x:
A combined view for audit and security sounds useful. Error tracking can stay separate since administrators don't need it in the app.