How should a web app separate audit, security, and error logging?

Security controls should match the sensitivity of the records. Some teams add a tamper-evident chain by storing a hash of the previous audit entry, while centralized logging systems can provide additional protection against modification. At minimum, restrict access, record who viewed or exported logs, and define retention policies deliberately instead of choosing one period for every category.

A practical starting point might be longer retention for business audit records, shorter retention for routine errors, and security retention based on compliance and incident-response needs. Pagination and background jobs are sensible for large searches or exports.

Treat the audit log as a product feature, not just ordinary diagnostic logging. Give it a stable schema, support filtering by date, user, and record, and avoid allowing normal application code to update or delete entries. Older audit data can be archived rather than keeping the live table indefinitely.

For security and audit records, consider sending copies to a centralized system outside the application database. That way a compromised account or broken deployment cannot quietly erase the evidence. A shared request or correlation ID across audit events, security events, and errors makes incident investigation much easier without merging all three types into one schema.

I would not build a replacement for the interfaces that specialized tools already provide. Send exceptions and frontend errors to Sentry, operational logs to a central log service, and performance traces to an observability tool. Keep the application database focused on audit records and perhaps the security events that the application actually needs to display.

Staging can go to Sentry too, but use a separate project and preferably separate quotas or sampling. A noisy test loop can consume the same quota as production surprisingly quickly.

I would keep audit and security events in separate tables. They have different schemas, retention periods, and audiences, so a single general-purpose log table tends to become difficult to maintain. If administrators need one screen, combine the data at the UI or reporting layer rather than forcing the database schemas together.

Audit entries should be append-only, tied to the employee and affected record, and protected with strict access controls. Security events can use a separate, more restricted dashboard for IT and developers. Application exceptions are better sent to Sentry or a similar service because it provides grouping, stack traces, alerts, and useful debugging context.