Websites
Site Activity Log
The Activity log is the per-site record of what has been done and by whom: every backup taken, PHP version changed, domain added, cache purged, SSH key installed and password reset, in one reverse-chronological list you can scan in seconds.
Where the Activity Log Lives
Open Websites, click the site, open the Advanced menu in the site tab strip, and choose Activity. The page is titled Activity log and describes itself as recent actions performed on this site.
There is no top-level Activity item in the main sidebar. The log is scoped to one site, which is what makes it useful: it does not mix in changes to your other sites, your billing, or your mailboxes.
Reading an Entry
Each row has four parts:
- An icon tile, colour coded by the kind of action. Removals and disables are red with a bin, creations and enables are green with a plus, updates and configuration changes are amber with a pencil, and logins, single sign-on events and restores are blue with a key.
- A plain-English label, such as PHP version changed, Backup created, Custom domain added or WP admin SSO login.
- A detail pill where there is something specific worth showing, for example the old and new PHP versions, the IP address that was blocked, or the name of the SSH key that was added.
- The actor and timestamp, on the right.
The detail pill is the part that makes the log genuinely useful during an investigation. Site URL updated on its own tells you little; Site URL updated with oldvalue to newvalue next to it tells you everything.
Who Did It
The actor line under each label shows the name of the KPanel user who performed the action, or their email address if they have not set a name.
Automated actions are attributed to System. Scheduled backups, automatic SSL renewals, cron-driven auto-updates and the like are all System entries. If you see a change attributed to a person that they say they did not make, treat it as a compromised login and work through Account Security and Two-Factor Authentication.
Entries are written by the platform, not by you, and there is no way to edit or delete one from the panel. That is the point: an audit trail you can rewrite is not an audit trail.
What Gets Recorded
The log covers the whole surface of the site, not just one area. Broadly:
| Area | Examples |
|---|---|
| Site lifecycle | Site created, site deleted, site settings updated |
| Access | WordPress admin single sign-on, phpMyAdmin single sign-on, SSH key added, SFTP user created |
| Backups | Backup created, backup restore requested, backup schedule updated |
| Domains and SSL | Custom domain added or removed, domain activated, SSL certificate renewed |
| PHP and server | PHP version changed, PHP settings updated, PHP-FPM reloaded, slow query log toggled |
| Caching | Redis cache enabled or disabled, full-page cache purged, URL cache purged |
| Security | IP address blocked, country access rules updated, XML-RPC block toggled, login lockout enabled, site password protection enabled |
| WordPress operations | Users created and deleted, roles changed, permalinks updated, plugins and core auto-updated, .htaccess saved, revisions deleted |
| WooCommerce | Gateway changed, order statuses updated in bulk, currency updated, stock updated |
| Deploys and environments | Staging created and synced, push to production, preview deployment built and destroyed |
| Files | File saved, renamed or deleted, database exported or imported |
If an action has no friendly label yet, the raw action name is shown instead of hiding the entry. Nothing is dropped just because it is new.
Refreshing
The list is loaded when you open the page and does not poll. Click Refresh in the top right to pull the latest entries after you have made a change in another tab.
The page loads the most recent 100 entries. Older activity is retained, but the panel does not paginate past that window, so if you need to reconstruct something from months ago, open a ticket and ask support to pull the audit record: see Opening a Support Ticket.
Using the Log In Practice
After Something Breaks
Start here before you start guessing. Open the log, look at the entries immediately before the time the site started misbehaving, and you will usually find the cause on the first screen: a PHP version bumped, a plugin auto-updated, a .htaccess saved, a cache setting flipped.
That is faster than reading error logs, because the log tells you what changed rather than what the symptom was. Once you have a suspect, Error Logs tells you exactly how it failed.
After a Handover
When you take over a site from someone else, the activity log is the shortest possible briefing on how it has been run: whether backups are being taken, whether updates are automatic or manual, whether anyone has been shelling in, whether security features are switched on.
As a Security Check
Two patterns are worth looking for specifically:
- SSH keys and SFTP users you do not recognise. Both are recorded with the label they were created under. Cross-check against Adding SSH Keys To a Site and revoke anything unfamiliar.
- Single sign-on logins at odd hours. Every WordPress admin and phpMyAdmin single sign-on is logged with the user who initiated it.
Take a screenshot of the relevant rows before you start fixing things. Entries stay in the log, but a screenshot with the timestamps visible is far easier to attach to a support ticket than a description from memory.
What the Log Does Not Show
- Changes made outside KPanel. Editing a file over SFTP is recorded as a file operation only when it went through the panel's file manager. Direct SSH work is not itemised, though the fact that a key exists is.
- Visitor traffic. For that, use the site's Analytics tab.
- Application-level events inside WordPress. Plugin actions taken from inside
wp-adminare WordPress's business, not the platform's, unless they were triggered from KPanel.
Where To Go Next
- Error Logs for the failure detail behind a change.
- Site Settings for the maintenance and HTTPS toggles that show up here as settings updates.
- Taking a Backup before you make a change you might want to reverse.