A WordPress admin plugin to Customize and secure your WordPress dashboard
Who signed in, what changed, from where
A WordPress activity log that collects eighteen event types in one filterable table, with the user, the IP address and the country on every row. When something stops working, or an administrator appears that nobody remembers creating, the answer is in there.
Monitor WordPress logins and reconstruct an incident minute by minute
Every entry carries a timestamp, the user, the IP address, the country, the action, the object it applied to and a short detail line. Filter by event type, search by user, address or object, and the sequence becomes readable.
Every address is a link on WordPress activity log. One click opens the IP lookup already filled in, showing the country, the network owner and the AS number behind the row — which is how you go from “someone tried to sign in” to knowing who and from where.
Privacy. The log stores IP addresses and usernames, which count as personal data under the GDPR. Mention it in your privacy policy along with the retention you actually apply: the ten-thousand-entry ceiling is not a time limit, so on a quiet site an entry can sit there for years.
An IP address is personal data whenever it can identify someone, even indirectly. Recording it does not require consent when it rests on legitimate interest: logging IP addresses for information security — blocking attacks, investigating abuse — is lawful without consent, provided the purpose and retention are documented.
Frequently asked
Five answers on what gets recorded, what it costs in performance, and what the GDPR expects from the data it keeps.
Open the WordPress activity log and filter by event type. Every row tells you who performed the action, when, from which IP address and on which object: the plugin activated, the theme switched, the content deleted, the settings page saved.
The most useful case is the least obvious one. When a site “breaks on its own”, somebody almost always activated or updated something shortly before. Cross-referencing the time of the failure with the log narrows the search to seconds, instead of a morning spent deactivating plugins one by one.
Eighteen types across three families. Authentication: sign-ins, sign-outs, failed logins, access refused at the login page, password resets, and blocks where the password was correct. Users: accounts created, accounts deleted and every role change. Site: plugins activated and deactivated, theme switches, updates installed, content published, unpublished or deleted, and saves to Deskmode’s own settings.
The one to watch is the block with a correct password: it means someone holds valid credentials and only your rules are stopping them from getting in.
No, and the reason is a design decision. Events go into a dedicated database table indexed by timestamp, action and IP. Many plugins store their logs in a WordPress option instead: that option is loaded on every request and rewritten in full on every new event, so the bigger it grows the more it costs.
The country on each entry is read from the cache the security module already filled, so writing a row never triggers an outbound request. And the log keeps only its ten thousand most recent entries, dropping the oldest, so it cannot grow without bound.
Yes — every address in the log is a link. One click opens the Network Info page already filled in with that IP and shows the country, region, city, ISP, organisation and AS number, with the location on a map and a check against five mail blacklists.
Next to the address there is also a Block button, which adds it to the blocklist without reloading the page. If the address is already allowlisted the button doesn’t appear at all: the allowlist takes priority, so blocking it would have no effect.
The log stores IP addresses and usernames, which are personal data. The plugin gives you the tools to handle them — collection can be switched off, the log can be emptied from the page with a confirmation, and nothing is ever sent to an external server — but compliance depends on how you use them.
Two things are on you. Document the processing in your privacy policy with the correct legal basis, normally legitimate interest in the security of the site, which the GDPR explicitly recognises for network and information security. And state a retention period you actually honour: the ten-thousand-entry ceiling is not a time limit, so on a quiet site an entry can remain for years. If you declare thirty days, you have to clear the log accordingly.