What Are Audit Logs? A Quick Definition, Setup Guide, and Best Practices

When something changes in your infrastructure, you often need to trace it back to who made the change and when. That's what audit logs are for: they provide a chronological record of the actions taken across your systems, tied to the person or service responsible for each one.

In this guide, you'll learn what an audit log is, how audit logging differs from your regular application deployment logs, how to configure database audit logs step by step, the most reliable ways to manage audit logs at scale, and how to use them to pass a security audit.

What is an audit log?

An audit log is a chronological record of the actions taken within a system, with each entry tied to the user or service responsible, the time it happened, and the resource it affected. Audit logging, meanwhile, is the practice of generating and storing those entries as events occur, whether that's a login, a file change, a permission change, or a configuration update.

A series of audit logs is known as an audit trail: a sequential history you can follow to reconstruct exactly what happened to a system over time.

Most audit log entries share the same core fields, regardless of which system produced them:

• Timestamp. When the action occurred, ideally synchronized across all your systems so events can be correlated accurately.
• Actor. The user ID, API key, or service account that performed the action.
• Action. What happened: was something created, updated, deleted, logged in, or deployed.
• Resource. The specific object affected, such as a file, a user account, or a server.
• Source. Where the action came from, such as an IP address or host name.

You may find audit logs described as a physical or digital record. In modern IT systems, they're digital, and they don't have to sit in a standalone file on disk – you can also send them to a dedicated log management tool or rely on a platform's built-in audit logging.

Audit logs vs. regular system logs

Audit logs and regular system logs both detail system activity, but they exist for different reasons.

• System logs help you troubleshoot issues, such as a crash report, a slow query, a timeout, or a failed health check.
• Audit logs exist to document accountability, i.e., who did what, so you can answer that question with confidence later.

Regular system logs, along with the metrics you collect for server monitoring, are typically kept only as long as they're useful for debugging and alerting.

Audit logs, by comparison, are built to be immutable. Once an entry is written, nothing, including an administrator, should be able to alter or delete it, since compliance frameworks generally require a verifiable, tamper-evident trail, not just a log that happened to survive.

Why audit logs are important

Audit logs solve several problems at once, making them an important part of a team's production stack:

• Regulatory compliance. PCI DSS explicitly requires audit logs, SOC 2 auditors expect evidence of access and change management, and GDPR requires you to demonstrate how personal data is protected. In each case, a documented trail carries more weight than a written policy.
• Security incident response. When something goes wrong, audit logs let your security team reconstruct the sequence of events: who accessed what, from where, and what they changed.
• Operational troubleshooting. A failed deployment or a broken configuration is far faster to diagnose when you can trace it back to the exact change that caused it.
• Dispute resolution. In a disagreement over who authorized a change or a transaction, an audit log entry is harder to argue with than someone's memory of events.

According to IBM's 2025 Cost of a Data Breach Report, organizations took a mean of 241 days to identify and contain a breach in 2025, the fastest pace in nine years but still a long time to reconstruct what happened without a clear trail to follow. A complete audit trail won't prevent a breach, but it will give your team a head start on working out what happened.

How to configure database audit logs

Teams commonly need audit logging on their databases, since they hold the sensitive data most compliance frameworks are there to secure. Here's a step-by-step setup for two of the most widely used options.

PostgreSQL, using pgaudit:

1. Install the extension on your server (on Debian or Ubuntu, this is apt install postgresql-<version>-pgaudit).
2. Add pgaudit to shared_preload_libraries in postgresql.conf, then restart PostgreSQL so the library loads.
3. Enable the extension inside the database you want to audit: CREATE EXTENSION pgaudit;
4. Set what to log in postgresql.conf, for example, pgaudit.log = 'write, ddl' to capture data changes and schema changes without logging every read.
5. Reload the configuration with SELECT pg_reload_conf(); and confirm entries are appearing in your PostgreSQL log output.
6. If PostgreSQL runs in a Docker container, as it does when you deploy it through Dokploy, install pgaudit in a custom image rather than on the host, and pass -c shared_preload_libraries=pgaudit as a startup argument instead of editing postgresql.conf.

MariaDB, using the MariaDB Audit Plugin:

1. Install the plugin: INSTALL SONAME 'server_audit';
2. Choose which events to capture: SET GLOBAL server_audit_events = 'CONNECT,QUERY_DDL,QUERY_DML_NO_SELECT'; This logs connections, schema changes, and data changes, but skips reads.
3. Turn logging on: SET GLOBAL server_audit_logging = ON;
4. Set a log file destination with server_audit_file_path, or set server_audit_output_type to syslog if you're centralizing logs elsewhere.
5. Add the same settings under [mariadb] in your server's config file, since SET GLOBAL changes are lost when MariaDB restarts.

In both cases, start with data changes and schema changes rather than logging every statement – though it gives you the most complete audit trail, it also adds real overhead, and most compliance requirements are more about who changed data than who viewed a dashboard.

Best practices to follow when managing audit logs

Once you're generating audit logs from more than one source, the focus moves to managing them effectively. These three approaches cover most situations:

Most teams end up combining at least two of these, for example: native audit logging at the database or application layer, centralized somewhere a security team can search audit logs across every system at once, with a platform's own audit log covering the infrastructure layer in between.

How to use audit logs to pass a security audit

If you have audit logs set up, you need to be ready to produce them on request. Before an audit, confirm the following:

• Completeness. Every entry captures who performed the action, what it affected, and when it happened. An auditor who finds gaps will ask why, and failing to answer reflects poorly on the rest of your controls.
• Immutability and data access control. Only authorized users can view audit log files, and no one, including administrators, can edit or delete entries after the fact.
• Retention that matches the framework. PCI DSS requires at least 12 months of history, with the last three months immediately available, while SOC 2 and GDPR don't set a fixed period. Confirm your policy satisfies the framework you're being audited against, and document the policy itself.
• An exportable, filtered view. Auditors don't want a raw log dump. Make sure you can filter audit log entries by user, date range, or resource, and hand over exactly what's relevant, to save everyone time.

Treat this as a quarterly check rather than something you scramble to confirm the week before an audit. By the time the request comes in, you want the answer to already be "yes."

Common audit logging challenges

Audit logging, like every vital process, has some inherent challenges.

• Storage costs climb quickly once you're logging write operations across multiple databases and services, especially if retention requirements push you toward keeping years of history rather than months.
• The audit log itself can also become a target for security breaches: if too many people can read or modify it, you've effectively created a second system that is open to unauthorized access.
• In a distributed setup with container monitoring spanning dozens of services, correlating a single event across every system it touched is genuinely difficult without a centralized place to search.

Because of these challenges, how you store, secure, and search audit logs deserves as much thought as turning logging on in the first place.

Audit logging in Dokploy

If you're running your applications and databases through a self-hosted platform, it helps to see what a platform-native audit log looks like.

Dokploy Enterprise includes an Audit Logs feature that records every meaningful action across your organization: logins and logouts, user and custom role changes, deployments, environment variable changes, and changes to applications, databases, Compose stacks, and domains.

Each entry in Dokploy's audit log captures a timestamp, the user who performed the action, the action type, the affected resource, and the role that user held at the time, and you can filter by user, resource name, action type, or resource type to find a specific event.

It's built into Dokploy's multi-tenant organization structure, so audit logs stay scoped to your organization rather than leaking across tenants.

Audit Logs are available on Dokploy Enterprise alongside features like single sign-on and SCIM provisioning. If you're already using custom roles to control who can do what, audit logs show you what those people actually did.

Conclusion

Audit logs are central to any team's monitoring and compliance efforts. With them in place, you no longer have to guess what happened to a system, as you'll have a verifiable record.

Whether you're setting up database audit logs for the first time, picking a way to manage them across your stack, or preparing evidence for a security audit, the fundamentals stay the same: capture the full chain of who, what, and when, keep the record tamper-proof, and make sure the right people can find what they need quickly.

If you want to see what platform-native audit logging looks like alongside the rest of your deployment workflow, contact us now, or sign up and try Dokploy.

Audit logs FAQs

How long should you retain audit logs?

Retention depends on the compliance framework and industry you're subject to. PCI DSS, for example, requires at least 12 months of audit log history, with the most recent three months immediately available. SOC 2 and GDPR don't set a fixed period, so your documented policy needs to justify the length you choose.

Can a user delete their own audit log entries?

No, not in a properly designed system. Audit logs are built to be immutable, and even administrators typically shouldn't have direct write or delete access to the audit log itself, since that would undermine the entire point of keeping one.

What's the difference between an audit log and an activity log?

The terms overlap, but audit logs focus on security- and compliance-relevant events, while activity logs can include broader, lower-stakes user behavior that doesn't need the same immutability or retention guarantees.