Users Activity shows a tamper-evident trail of changes made in the panel — who did what, when, from which IP, and what values changed. It’s your go-to page for auditing configuration edits, restores, and administrative actions.

Who can view this

• Requires the users_activity_logs permission.
• If your account is scoped to certain servers, you’ll still see global actions (e.g., role edits) but schedule/server changes are visible only for servers you’re allowed to access.

What’s recorded

• INSERT / UPDATE / DELETE on core entities: servers, storages, schedules, users, roles.
• RESET / EXECUTE / RESTORE actions (e.g., SSH link reset, “Run now”, Disaster Recovery / cPanel restores).
• Login/Profile/License related changes (account edits, license key events).
• For data edits, the logger stores diffs — only the fields that changed, not the entire row.

Filtering & housekeeping

• Use the Date from / Date to pickers and click Filter results to limit the window (the end date is inclusive).
• Clear activity logs removes all entries (useful after exports or drills). It doesn’t affect backups, users, or schedules.

Columns explained

• Date — when the action was captured (panel server time).
• IP Addr — source IP of the user who performed the action.
• Username — account that triggered the action.
• Action — INSERT, UPDATE, DELETE, RESET, EXECUTE, RESTORE.
• Page — target entity (links to the corresponding page: servers, storages, schedules, users, roles, license).
• ID — the affected row identifier (also linked when applicable).
• Old values / New values — key/value pairs that changed, rendered as a minimal diff.

Typical use

• Trace who edited a schedule’s retention or transfer mode, and what the previous values were.
• Confirm when a server was deleted and by whom (with IP).
• Verify that a Disaster Recovery or cPanel restore was initiated, and correlate with Backup Logs.

Good to know

• Sensitive fields (passwords, tokens) are not echoed in plaintext; only the fact of change is recorded.
• Links in the Page and ID columns take you directly to the relevant edit/detail screens.
• For large environments, filter by date first — activity can be very chatty during migrations or mass edits.

Troubleshooting patterns

• Frequent UPDATE on schedules around the same time as failures → a recent change may have broken a job; open the schedule and compare diffs.
• Many DELETE actions → check for accidental removals or cleanup scripts run by admins.
• No entries during an incident window → confirm your date range and permissions; also check Backup Logs for job-level detail.