Audit Logs
The trail of actions dashboard users took on this server. Audit Logs shows who changed what and when, what each entry recorded, and what the trail does not capture.
What the audit log is
The audit log is the trail of actions dashboard users took on this server. Someone changed a project's timezone, deleted a funnel, signed in, edited a member. Each entry names the account, the time, the address the request came from, the action, and, where there was one, the change itself.
It answers "who changed this, and to what?" It does not answer why something failed. Errors and stack traces are in the server's own process logs, which are not shown in the dashboard; ask whoever runs your server to read them where your deployment collects them.
The trail covers the whole server. Only global administrators can open it, and it is not scoped to a project even though many entries name one, so one table holds every project's history side by side.
Entries are only ever added. Nothing on this page edits or removes one, so what you read is what was recorded at the time.
How an audit entry is written
An entry appears the moment an action succeeds, and it records what that action changed. The trail is never filled in afterwards or reconstructed from the current state, which has three consequences worth knowing.
A failed action usually records nothing. If a save was rejected, an entry is normally not written, because the entry is written after the change succeeds. The exceptions are the actions whose failure is itself the interesting event, and those have their own codes: a rejected sign in records a failed login, not a successful one.
An action that changed nothing usually records nothing. Most update entries are kept only when a field actually differs, so pressing Save on a form you did not edit usually leaves no trace. An empty audit log after someone insists they saved something usually means they saved the same values back.
What an entry carries depends on the action. Update actions record the fields that changed with their old and new values, which is what the expanded row shows as Before and After. Creation actions carry the new object. Sign in and sign out actions carry nothing at all, because there is nothing to describe beyond the fact and the time. Different actions record different fields, so do not expect the same detail in every entry.
The account, timestamp and address come from the request rather than from the action. The address is the address Countly saw the request arrive from, which behind a proxy or a load balancer may be the proxy rather than the person, and it is left blank when the server is configured not to record addresses at all.
An action an AI assistant took through MCP, or any request made with a token from Token Manager, is recorded against the account the token belongs to, like the account's own actions. A line under the account names the token, for example "via MCP: Claude", so these entries can be told apart from what the person did in the dashboard. A project the MCP settings create for usage data reads "via MCP settings" the same way.
Entries are immutable. Nothing in the dashboard edits or deletes one, which is the point of an audit trail, and it is also why the record only grows.
Use Cases
Find out who changed something
A setting, a project or a dashboard object is not what it was, and you need to know who changed it and to what.
- Open Audit Logs from the Manage menu.
- Set the period wide enough to contain the change. The period filters on entry time, so a change made three weeks ago is invisible under a seven day window, and starting too wide costs nothing.
- Narrow with the Action filter rather than by reading. Pick the action that matches what changed, for example Project updated for a project's settings or Server settings changed for a server wide one.
- Read down the User column. The table opens newest first; sort by Time to reverse it.
- Click the entry. The panel underneath shows the fields that changed with their previous and new values side by side.
If the table is empty after you pick an action, the action happened on this server at some point but not inside the period, so widen the period. If the change is not there at all, the likely reasons are in the reference section on what the audit log does not record: changes made outside the dashboard and saves that changed nothing leave no entry.
Review what one account did
An account is being offboarded, or its behavior is in question, and you need everything it did.
- Open Audit Logs and set the period to cover the whole time you care about.
- Open the User filter and pick the account. It lists every member of the server, so an empty table afterwards means the account did nothing recorded in that period.
- Leave the Action filter alone. The point of this pass is breadth, and the two filters combine, so adding an action would hide everything else the account did.
- Read the table with the context lines under the Action column, which name the project, the user or the object each action was about.
- Press Export and download the result. The export covers every entry matching the current filters and period rather than the page on screen, which is what makes it usable as evidence.
The User filter and the search box are independent, so you can keep a user selected and still search. The Action filter is not: typing a search replaces it. If you need both an account and a single action, use the User and Action filters together and leave the search box empty.
An account that was deleted still appears in its old entries. The trail records who acted at the time and is never rewritten, so removing a member does not remove their history. A deleted account is no longer offered in the User filter, which lists current members, so export the period and look for its email address in the file.
FAQs
Someone changed something and there is no entry. Where did it go?
The likeliest answers, in order: the period does not cover it, the save changed nothing so nothing was written, or the change was not made through Countly at all. Changes written directly to the database, by a script or by a migration never reach this trail.
Are changes made through the API recorded?
Yes. A change made through the API with an account's API key is recorded like a dashboard change, and its entry names that account.
Can I see who viewed a project or ran a query?
No. The audit log records changes, not access. There is no read trail anywhere in Countly.
Why does searching for "Project updated" find nothing?
Because the search is compared against the stored action code, not the readable label. Search app_updated, or use the Action filter, which lists the labels and sends the codes for you.
Why is the Action filter greyed out?
Because the search box has text in it. The two cannot be combined, so clear the search to get the filter back. The User filter works either way.
Why do some rows not expand?
Because that action recorded no data. Sign in, sign out and API key retrieval are the fact and the time, with nothing to describe, so there is no panel and no arrow.
Why is the IP address column empty?
Because the server is configured not to record addresses. Nothing else about the entry is affected. Where addresses are recorded, an address behind a proxy or load balancer may be the intermediary's rather than the person's.
How long are audit entries kept?
Until someone who runs the server removes them. Nothing in the dashboard prunes them and no dashboard action deletes one.
Can I delete an audit entry?
No. An audit trail that could be edited from the dashboard would not be one.
Where do I find the server's error logs?
Not in the dashboard. The server's process logs are collected wherever your deployment sends them, so ask whoever runs your server. The audit log tells you who did something; those logs tell you why a request failed.
Why can my project admin not open this page?
Because the audit log is server wide and only a global administrator can read it. There is no per project view of it.