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.

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.

Agent actions are actions

Work done by agents lands in the same record as work done by people. There is not a separate log for it.

That is the correct design and worth relying on: “what happened in this organization” has one answer, not one per kind of actor.

What it is not

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

It is also not the place to reconstruct why a build did what it did. Events tell you a build ran. The run itself tells you what it did, step by step. See runs.

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.