Account
Reading Your Account Audit Log
The audit log is a permanent, filterable record of every action taken inside your Kapsule account, showing who did it, what they touched, when, and from which IP address.
It is the first place to look when something changed and nobody remembers changing it: a DNS record that moved, a mailbox that disappeared, a subscription that was cancelled. It is also the record you export when an auditor or an insurer asks you to evidence who has access to your infrastructure.
Opening the Audit Log
- Go to Settings.
- Click Account in the Workspace group of the settings rail.
- Find the Audit log card, described as "Full history of account activity".
- Click View log.
The log is at /settings/audit-log if you prefer to go straight there.
What Each Column Means
| Column | What it holds |
|---|---|
| When | How long ago the action happened, shown as "just now", minutes, hours, or days. Hover over it to see the exact date and time in your own locale. |
| Actor | The name or email address of the person who performed the action. Automated actions taken by the platform itself, such as a scheduled renewal charge, are attributed to System. |
| Action | A short machine-readable code in a coloured chip, for example site.created or domain.dns.updated. |
| Resource | The type of thing that was affected and the beginning of its internal identifier. |
| IP | The IP address the request came from, or a dash where no address was recorded. |
The When column tells you the order of events, but the Actor and IP columns are the ones that matter during an incident. An action attributed to one of your team members but coming from an IP address in a country none of them has ever worked from is the clearest signal you will get that a login has been taken over.
Action Names and What They Cover
Action codes are grouped by the part of the product they belong to, and the chips are colour coded by group. The families you will see most are:
site.*for anything done to a website: created, deleted, settings changed, PHP version changed.mailbox.*for mailbox creation, deletion, quota and password changes.domain.*for registrations, transfers, renewals, and nameserver changes.dns.*for individual DNS record changes.email.*for changes on the mail platform.subscription.*andbilling.*for plan changes, cancellations, and payment events.api_key.*for API keys being created and revoked.auth.*andaccount.*for sign-in security events, password reset requests, and email changes.
Some action codes were named years ago after the systems that used to sit behind a feature. The log rewrites those to neutral names before displaying them, so what you read on screen is the current product vocabulary even where the stored value is older.
Filtering the Log
Two filters sit above the table.
Filter by action is a free-text box. It matches on the action code, so typing domain narrows the view to domain events and typing deleted finds deletions across every product area. This is the fastest way to answer "when was this deleted, and by whom".
All types is a dropdown that narrows by the kind of resource affected. The available types are site, mailbox, domain, subscription, dns_record, and api_key.
The two filters combine. Choosing the domain resource type and typing delete in the action box shows only domain deletions.
The table loads a page at a time. Click Load more at the bottom to fetch the next batch. Filters are applied on the server, so a filtered view pages through the whole history rather than only the rows already on screen.
Exporting for Compliance
Click Export CSV in the top right. The download contains the rows currently loaded on screen, with the columns Timestamp, Actor, Action, Resource Type, Resource, and IP. The timestamp is a full ISO date and time, not the relative "3d ago" the table shows.
The export takes what is loaded, not the entire history. If you need a long period, click Load more until you have paged back far enough, then export. Apply your filters first so you are paging through a much smaller set.
The CSV opens cleanly in any spreadsheet application. For an annual access review, exporting the api_key resource type alongside a screenshot of your team member list is usually all an auditor wants to see.
Using the Log During an Incident
If you believe someone has reached your account without permission, work through the log in this order:
- Filter by nothing at first. Scan the most recent day for actions you do not recognise, in any product area.
- Note every distinct IP address attached to actions you did not take.
- Check the actor. If the actions are attributed to a real teammate, their login is the problem, not the account as a whole.
- Check for
api_key.created. Creating an API key is a common way an intruder keeps access after you change a password, because keys survive a password reset and a session sign-out. - Check for
account.email.change_initiated. An attempted email change is a strong signal of an account takeover attempt.
Then act: revoke sessions and keys, change the password, and enable two factor authentication. Account Security has the full sequence, and What to Do If Your Site Is Hacked covers the site side.
What the Audit Log Does Not Cover
The audit log records actions taken through Kapsule: the panel, the API, and our automated jobs. It is not a web server log and not an application log.
It does not contain:
- Requests to your website. Those are in your site's access and error logs.
- Actions taken inside your application, such as a WordPress user editing a post.
- Actions taken over SSH or SFTP directly against the filesystem.
- Email that was sent or received. Mail flow is recorded separately.
If you are investigating a site compromise rather than an account compromise, the audit log tells you whether the attacker came through your Kapsule login, and your site's error and access logs tell you whether they came through the application. You usually want both.
Troubleshooting
The log is empty. A new account with no activity yet shows "No audit log entries yet." Create or change something and refresh.
An action I definitely took is missing. Audit entries are written as a side effect of the action and are not allowed to block it, so an entry can occasionally be lost while the change itself succeeds. Treat the log as strong evidence of what happened, not as proof that nothing else did.
The IP column shows a dash. No client address was recorded for that request, which is normal for actions performed by the platform itself, such as an automated renewal.
I need entries older than the log shows. Keep paging with Load more. If you have reached the end and still need older records, open a support ticket and quote your Support Key from Settings, then Account.