Audit log

The audit log is your organization’s record of what happened: who did what, and when.

It is reverse-chronological, filterable, and each event expands to its detail. You can export it.

Reading it is an administrator capability. Members and viewers do not have it, because an audit trail that everyone can read is a map of who is worth watching.

Two properties make it a record rather than a log:

• Nothing can edit or remove an event. Not an administrator, not the owner. The trail only grows.
• An action and its record succeed or fail together. The record is written as part of the action itself, so there is no window where something happened and the trail missed it.

What it is for

Two jobs, and they pull in different directions.

Answering a question after the fact. Who changed that policy. When was that person’s access removed. Filters and detail expansion serve this.

Producing evidence. Compliance questions want a record you can hand over rather than a screen you can look at. Export serves this.

It records decisions, not work

The audit log is deliberately narrow. It records the things that change what your organization is or who can reach it: a policy published, a member added or removed, a role changed, a domain verified, an environment variable set, an export requested, erasure scheduled.

It does not record the work. Planning an initiative, running it, generating a document, deploying: none of that is here, on purpose. Those are product activity with their own surfaces, the run and the activity feed, and folding thousands of routine agent steps into the same record would bury the fifty entries a compliance question is actually about.

The exceptions all share one shape: an action that would otherwise leave no trace anywhere.

When Taiga plans a fix for an urgent vulnerability on its own, that dispatch is recorded, along with the ones it considered and skipped. Autonomy that leaves no trace is the kind worth logging.

Two queue actions are here for the same reason. Removing an initiative from the queue deletes the entry outright, and resuming a stopped one clears the record of what stopped it, so afterwards neither the queue nor the initiative can say either happened. Adding to the queue is not recorded: the entry itself already says who queued it and when. Neither is reordering, which loses only the previous order and happens far too often to be worth burying the rest of this log under.

An autonomous merge is recorded here too, as build_run.auto_merged. Your repository shows the merge, but not why Taiga was allowed to make it, and that is the part a compliance question asks about. The entry names the pull request and the merge commit, and records the four consent switches, organization, factory, product and initiative, exactly as they stood when the merge was permitted, including which ones were never set and simply inherited. The actor is the system, because no person pressed merge; the person who started the run is kept on the entry as the work’s author.

Adding someone to an initiative’s subscribers, or taking them off, is recorded as initiative.subscriber_added or initiative.subscriber_removed. It decides what reaches another person, and nothing else says who did it. Subscribing or unsubscribing yourself is a preference, and is not recorded.

What it is not

It is not application monitoring. It records what happened to your organization in Taiga, not whether your products are healthy. That is monitoring.

And when the question is what an agent did rather than what was configured, the answer is on the run, which keeps every step, decision and change.

Export it before you need it

The useful habit is exporting once, early, to see the shape of the record while nothing is at stake.

Finding out what your audit trail does and does not capture during an actual incident is the wrong time to find out.