Audit Logs and Authentication Logs

RackHelm keeps two separate histories, and knowing which one answers your question saves a lot of time. The audit log records changes to data — who edited what, and what the values were before and after. The authentication log records sign-ins and sign-outs for one account, with IP address and approximate location.

Before you start #

Note: The audit log requires view_audit_logs; an account’s authentication log requires view_client_activity as well as view_clients. The two are separate on purpose — view_audit_logs is also deliberately separate from view_settings, so a reviewer can read history without being handed the settings screens.

Tip: The sidebar entry Security → Audit Logs is only rendered for Super Admins, because the whole Security group is gated on a capability name that is never granted. Staff holding view_audit_logs can still reach the screen at /admin/audit-logs directly.

The audit log #

What gets recorded #

Most of the platform’s data models write to the audit log when they are created, updated or deleted — accounts, roles, permissions, addresses, countries, orders and order items, invoices and invoice entries, credit transactions, products, product groups, add-ons, billing cycles, custom fields, coupons, departments, canned replies, email routes and templates, payment gateways and stored payment methods, settings, server integrations and panel accounts, notification channels and subscriptions, sites, site templates, SSL certificates and system schedules.

Three rules shape what you actually see:

• Only changed attributes are stored. Saving a form without altering anything writes nothing.
• Passwords and session tokens are never recorded on account entries, even when they change alongside something else.
• Secrets are masked when the entry is displayed — settings values, panel credentials and integration configuration are redacted at render time, so historic entries written before masking existed still cannot be read out of the log.

Filtering #

Reading an entry #

Rows page at 50 and show Date & Time, User (Causer), Action, Resource (Subject) and a View Data button. The causer links to the account that made the change; System / Guest means no one was signed in — a queued job, a scheduled task, a gateway webhook or an unauthenticated request. View Data opens the stored attributes, which for an update includes both the old and new values.

Warning: The causer is whoever was signed in, which during an impersonation session is the customer, not the operator. See Impersonating a Client for what impersonation does and does not leave behind.

Authentication logs #

Open a customer in Users & Roles → All Users and select the Auth Logs tab. This is the screen to use for “was it really them?” questions.

The geolocation lookup runs after the response has been sent, over HTTPS, with a two-second timeout, and failure is silent — sign-in is never delayed or blocked by it. That is why an entry can sit at Unknown Location permanently: the lookup was attempted once and did not answer.

Note: Impersonation does not appear here. Taking over and leaving a customer’s session are performed without raising sign-in events, so the customer’s history stays clean — but you also cannot use this tab to detect that a colleague impersonated them.

What customers can do themselves #

From Account → Edit Profile, under Device & Session Management, a customer can select Forget Devices & Log Out. The action asks for their current password, then revokes every 30-day trusted two-factor device, invalidates all other sessions and signs them out of the current one, returning them to the login page. It is the right advice when someone reports an unexpected entry in their sign-in history.

Retention #

Neither table is trimmed by any of RackHelm’s scheduled tasks, so both grow indefinitely. On a busy portal the audit log is by far the larger of the two. If you need to cap it, run the underlying clean-up command from the application directory on a schedule of your own:

php artisan activitylog:clean --days=365

Warning: That command deletes history permanently. Check your own record-keeping obligations before choosing a retention period, and take a database backup first.

Troubleshooting #