Every serious system needs a memory of its own actions, and that memory is the audit log. It is not the feature anyone buys software for, and it sits unread for weeks at a time, which is exactly why it is easy to build badly. The value of an audit log is entirely in the moment you need it and it is either there in full or it is not. When a record changes and nobody remembers doing it, when a customer swears they never approved something, when an account behaves strangely at three in the morning, the audit log is the only witness in the room. This post explains what one is, what separates a useful log from a decorative one, and how the audit log in Atlas is built, since I can speak to that one honestly.
The plain definition first. An audit log is an ordered, append-only record of events. Each entry answers a small set of questions: who performed an action, what the action was, which object it affected, and when it happened. Append-only is the load-bearing phrase. Entries are added and never edited or removed in normal operation. That property is what makes the log trustworthy, because a record you can quietly rewrite proves nothing about the past.
Why it matters, in four different rooms
People reach for an audit log for reasons that feel unrelated until you see the common thread. The first room is security. When an account is compromised or an insider does something they should not, the log is how you scope the damage: what did this actor touch, and when did it start. Without a timeline you are guessing, and guessing during an incident is how a small breach becomes a large one.
The second room is accountability. In any system where more than one person can change shared data, disputes are inevitable. Who deleted the record, who changed the price, who approved the refund. An audit log turns those arguments from opinion into fact, which protects the innocent as often as it catches the careless. The third room is debugging. Half of the confusing bugs I have chased were not code faults at all but someone changing a setting and forgetting. A log that shows the setting changed, by whom, at what minute, ends the investigation in seconds. The fourth room is compliance readiness. Auditors and security reviewers ask for evidence that you can answer the who-did-what question, and a real log is that evidence. It is one of the concrete controls sitting beneath the certificates people chase, a point I make at length in a separate post on what a SOC 2 report actually proves.
What separates a good log from a useless one
The word "audit log" on a feature page tells you almost nothing, because the range in quality is enormous. Four properties decide whether it will help you on the day you need it. The first is immutability. If an administrator can edit or delete entries, the log records only what someone was willing to leave in it, which is not the same as what happened. A trustworthy log is append-only by design, so even the highest privileged user adds to the record rather than rewriting it.
The second is completeness. A log that captures logins but not data changes will fail you at the exact moment a data change is the question. The events that matter most are the sensitive ones: permission changes, deletions, exports, and administrative actions. The third is searchability. A log you cannot filter by person, by object, or by time window is a haystack, and during an incident nobody has hours to scroll. The fourth is portability. You should be able to export the log so it can flow into whatever monitoring or long-term storage you already use, and so the record outlives any single screen inside the product. Miss any one of these and the log becomes decoration, and decoration is dangerous because it looks like protection.
| What a good log captures | Why that field earns its place |
|---|---|
| Actor | The identity that performed the action, whether a person or an automated process, so responsibility is never anonymous. |
| Action | The specific verb: created, updated, deleted, exported, granted, revoked. Vague actions make the log unreadable. |
| Object | Exactly which record or setting changed, identified precisely enough to find it again later. |
| Timestamp | When it happened, to the second, in a consistent time zone. Order is meaningless without accurate time. |
| Before and after | For changes, the old value and the new one, so you can see what actually shifted, not just that something did. |
| Context | Where the action came from, such as the session or the device, which turns a lone entry into a story. |
The audit log in Atlas, described honestly
I can talk about this one from the inside because I built it. Atlas keeps an audit log across the work graph, and it exists for a specific reason that shapes its design. Atlas is not only a place where people change records; it also has an assistant that can act on the work. The moment software can take actions on your behalf, an accurate record of those actions stops being a nicety and becomes the mechanism that makes the whole thing safe to trust. So the assistant does not get a private, unlogged channel. When it reassigns a task, files a document, or moves a record, that action lands in the same log as a human action, attributed and timestamped.
That design choice is deliberate and it connects to how the assistant is built. It acts under the acting person's own permissions, with approvals for anything consequential, and every action it takes is written to the log. In other words, an automated action is held to the same standard of accountability as a human one, which is the only honest way to give software the power to change your data. I write about the principle behind that in a piece on least privilege, because a log and tight permissions are two halves of the same idea: limit what can be done, and record everything that is.
Where the honest limits are
Two honest caveats belong here, because a post on audit logs that only lists strengths would contradict the point of having one. First, an audit log is a record, not a guard. It tells you what happened; it does not by itself stop a bad action from happening. It works alongside permissions, not instead of them. A log is the accountability layer, and access control is the prevention layer, and a system needs both. Second, a log is only as honest as the vendor behind it. You are trusting that the entries are complete and that they cannot be quietly rewritten. That trust should be earned with plain descriptions rather than assumed from a logo, which is why wrxstack publishes what it does and does not do on the security page and the trust page rather than hiding behind vague assurances.
I will also state a boundary plainly, in keeping with how everything else here is written. wrxstack is a small, independent operation, and it holds no formal security certifications today. The audit log in Atlas is real and I stand behind how it is built, but it is a product feature, not a certified compliance program. If your organization requires an audited vendor before it will trust any logging claim, that is a fair requirement, and it is one wrxstack does not meet yet. I would rather you know the shape of that limit now than discover it later.
How long a log should live, and where it should sit
Retention is the question people forget until they need an entry that no longer exists. A log that only keeps the last week is fine for casual debugging and useless for an investigation that surfaces months after the fact, which is when the serious ones usually surface. There is no single correct answer, because the right window depends on what you are protecting and what you may one day need to prove. The instinct that serves you well is to keep sensitive events longer than you think you will need them, because the cost of storage is trivial next to the cost of a gap on the day a regulator, a customer, or your own conscience asks what happened.
Where the log sits matters just as much as how long it lasts. A log stored only inside the product it records is fragile, because the same incident that corrupts the system can take the record with it. This is the deeper reason exportability is not a convenience feature. A log you can send elsewhere can be kept in storage that the recorded system cannot reach, which means the record survives even if the system does not. When you evaluate a tool, ask not just whether it logs, but how long it holds the log and whether you can get a copy out into your own hands. A record you control is worth more than a record you can only view.
How to evaluate an audit log before you rely on it
If you are choosing a tool and the audit log matters to you, do not accept the checkbox at face value. Ask whether the log is truly append-only, including for administrators, and ask what specifically cannot be edited. Ask which events are captured, and press on the sensitive ones: are permission changes, deletions, and exports all recorded, or only logins. Ask whether the log records before-and-after values for changes, because knowing that a field changed without knowing what it changed to is often useless. Ask whether you can search and export it, and in what format. The quality of these answers separates a vendor that treats accountability as a design principle from one that added a log to pass a checklist. That distinction is worth as much as any badge on the page, and often more.
What is the difference between an audit log and a regular application log?
A regular application log records technical events for engineers, like errors and performance data, and is often noisy and short-lived. An audit log records who did what and when in business terms, is meant to be immutable, and is kept so you can reconstruct actions later. They serve different readers and different purposes.
Does Atlas have an audit log?
Yes. Atlas keeps an append-only audit log across the work graph, and actions taken by the assistant are written to it too, attributed and timestamped, on the same footing as human actions. It is a real product feature. It is not a certified compliance program, and wrxstack holds no formal certifications today.
Can an administrator edit or delete audit log entries?
In a well-built log, no. The defining property of a trustworthy audit log is that it is append-only, so entries are added and never quietly rewritten, even by the highest privileged user. If an administrator can edit the log, it records only what someone chose to leave in, which is not the same as the truth.
Why does an audit log matter for compliance?
Reviewers ask for evidence that you can answer who did what and when, especially for sensitive actions like permission changes and data exports. A real, searchable, exportable audit log is that evidence. It is one of the concrete controls that certificates are meant to describe, not a substitute for them.