Investigating a WordPress change or login
Use the activity timeline to answer a client's question, trace an unexpected website change, or review suspicious login attempts.
7 min read
Start with the website and time window
Open Websites -> WordPress Activity, choose the affected website, and set the From and To dates around the time the client first noticed the issue. Start with a slightly wider window than the reported time because the client may have seen a cached page or noticed the result after the original WordPress action.
Narrow by the kind of change
Choose a category such as Content, Media, Users, Plugins & themes, Settings, Authentication, Comments, Menus, or Taxonomies. If you know the exact action, narrow it again to events such as Content updated, Plugin updated, User role changed, Media deleted, or Failed login. Keep the category broad when several related actions may have happened in the same request.
Confirm who performed the action
Review the WordPress display name, username, role, IP address, and source on the event. A REST source commonly means the block editor, Site Editor, or another WordPress integration saved through the REST API. A system or cron event can represent an automatic WordPress task rather than a person clicking in wp-admin. Treat IP addresses as one part of the evidence, especially when a website sits behind a reverse proxy or several staff share an office connection.
Compare what changed
Open View details and read the changed fields. For normal content, the before-and-after excerpt is centred on the changed area. Builder and ACF values are flattened into a bounded, readable representation. Character lengths help distinguish a small text edit from a large replacement. Use the affected-item link to open the current WordPress record and confirm its present state.
Review the surrounding events
Clear the action filter but keep the website and date range. Look for related activity immediately before and after the event, such as a plugin update followed by a settings change, a page edit followed by a media deletion, or several failed logins followed by a successful login. This sequence often explains more than one row viewed in isolation.
Handle suspicious logins
Filter the Authentication category and Warning severity to find failed logins. Repeated attempts for the same username and IP are grouped in five-minute windows, and the occurrence count shows the size of the burst. Search the same username or IP across the wider date range and check whether a successful login followed. If the activity is not recognised, reset the account password, review its role and sessions, and follow your agency's incident-response process.
Know when to check outside WordPress
If the page changed but no matching WordPress event exists, confirm the connector was active and at version 1.6.0 or newer at that time. Then review hosting deployments, SFTP or SSH access, CDN or cache behaviour, database imports, and server-level file monitoring. The Destiny Manage log is an audit trail for actions captured inside WordPress, not a replacement for host and operating-system logs.