How to Track Failed Login Attempts in WordPress

If your WordPress login page is public, it's being probed. Bots try common usernames and leaked password lists against wp-login.php around the clock, hoping one combination sticks. Most of the time you never notice — until an account gets compromised and you're trying to reconstruct what happened from nothing.

The fix starts with visibility. Before you can block an attack, you have to be able to see it: who's trying to log in, from where, how often, and whether they're succeeding. This post explains why failed logins matter, what WordPress records on its own (spoiler: nothing lasting), and how to track every login attempt with Logify — then turn that insight into action.

A single failed login is meaningless — you fat-fingered your password. A pattern of failed logins is a signal.

Two of the most common attacks against WordPress both show up as failed logins first:

Brute-force attacks hammer one or a few accounts with thousands of password guesses. You'll see the same username tried over and over from one or a handful of IPs.
Credential stuffing replays username/password pairs leaked from other breaches. This looks different — many different usernames, often one or two attempts each, frequently spread across many IPs.

In both cases, the failed attempts are the early warning. A spike at 3 AM, a burst of tries against admin, or a sudden wave of logins from a country where none of your users live — these precede the actual breach. Spot the spike early and you can act while it's still just noise. Miss it, and the first you'll know is a defaced homepage or a rogue admin account.

This is exactly the kind of question an activity log is built to answer — and the broader case for one is covered in our WordPress activity log guide.

What WordPress logs by default

Almost nothing — at least nothing that survives.

Out of the box, core WordPress does not keep a persistent record of login attempts. A failed login shows the visitor a generic error on the screen, and that's the end of it. There's no admin page where you can review who tried to log in, what username they used, or which IP they came from. Successful logins aren't logged either.

Your web server's access log will show POST requests to wp-login.php, but that's raw, hard to read, rotates away quickly, and doesn't tell you whether each attempt succeeded or which username was tried. For security work it's close to useless.

So if you want a real, readable, persistent WordPress login log, you need to add it. That's what an activity log plugin does.

How an activity log captures every attempt

An activity log plugin hooks into WordPress's authentication events and writes a row every time someone tries to log in — success or failure. For each attempt, a good log captures:

Timestamp — exactly when it happened, in a consistent timezone.
Username tried — including usernames that don't exist on your site (a strong credential-stuffing tell).
IP address — where the request came from.
Geolocation — the country/region mapped from that IP.
Result — success or failure.

That combination is what turns "something's wrong" into "here's what's happening." Logify records all of it for both successful and failed logins, maps each IP to a location, and gives you a clean, filterable interface to read it. The login event reference lives in the activity log docs.

Track failed logins with Logify, step by step

Here's the full workflow, from install to an audit-ready export.

1. Install and activate Logify

From your dashboard, go to Plugins → Add New, search for Logify, install and activate. It starts recording immediately — no configuration needed to begin capturing login events. The getting started guide covers first-run setup if you want to tune retention and roles up front.

2. Open the activity log

Open the Logify menu and go to the Activity Log. You'll see a list of every recorded event with a colour-coded severity badge, the user, the IP, and a timestamp. Login events are in here from the moment the plugin is active.

The filter bar above the table is where this gets useful. Narrow the event type to login/authentication events, then set the minimum severity to surface failed attempts (failures are logged at a higher severity than routine successful logins). You can also filter by date range to focus on a suspicious window — say, overnight.

What you're looking for:

The same username tried repeatedly → brute-force against that account.
Many different usernames, especially ones that don't exist → credential stuffing.
A cluster of failures from one IP → a single attacker you can block.
Failures from unexpected countries → traffic that has no business hitting your login.

4. Read the IP, location, and username tried

Click into an entry to read the full detail: the exact username that was submitted, the source IP, the resolved location, and the result. This is the part raw server logs can't give you cleanly. The username-tried field alone often tells the whole story — a wall of attempts against admin, administrator, and your domain name is a bot working a list, not a confused user.

5. Set a real-time alert or email digest for spikes

You don't want to sit and watch the log. Let it watch for you.

Real-time notifications (PRO) can fire the moment failed-login activity crosses a threshold, routed to email, Slack, a webhook, or syslog — each with its own severity filter and a rate limit so a brute-force burst doesn't bury you in fifty messages. Setup is in the notifications docs.
The email digest gives you a scheduled summary — including a brute-force burst count for the period — so even on quiet weeks you get the story without opening the dashboard. See email digest.

A good baseline: a real-time alert for any sharp failed-login spike, plus a daily or weekly digest for the slow-burn patterns.

6. Export the records

When you need to document an incident — for your own files, a client, or a compliance reviewer — use Tools → Export Logs. Filter to the login events you care about and download as CSV, JSON, HTML, plain text, or a paginated PDF. The JSON export is handy if you want to feed login data into another tool or a JSON feed; the PDF is built to hand to an auditor as-is.

Keeping login records is also part of meeting audit obligations — see our guide to a WordPress audit log for GDPR and HIPAA compliance.

Turning insight into action

Here's the honest part: Logify shows you the attack — it doesn't stop it. It's the visibility and auditing layer. When the log tells you you're under pressure, you pair it with tools that actively block:

Use strong, unique passwords on every account, especially admins. Most brute-force attempts fail purely because the password isn't guessable.
Turn on two-factor authentication for admin and editor accounts. Even a correct password then isn't enough to get in.
Add a limit-login or firewall plugin that locks out an IP after N failed attempts and rate-limits wp-login.php. This is the active blocking that complements Logify's visibility.
Block the worst offenders at the host or firewall. Once the log hands you a specific attacking IP and its country, you can deny it at your server, CDN, or WAF — upstream of WordPress entirely.

Think of it as a loop: Logify tells you who and what, your firewall and 2FA handle the stop, and Logify's export gives you the record afterward. Each side covers what the other can't.

Reducing noise with exclusion rules

If you log every authentication event, your own logins and known automated services can clutter the view. Logify's exclusion rules (Settings → Exclusions) let you keep the log focused on what matters — exclude your own user ID during heavy maintenance, or exclude the IP of a trusted uptime/cron service so its activity never reaches the log in the first place.

The point isn't to hide data — it's to make a genuine spike obvious. When the only login events left are the ones you didn't generate, an attack jumps off the page. If something looks off after tuning, the troubleshooting guide covers common questions.

Conclusion

WordPress won't tell you about failed login attempts on its own — there's no persistent login log in core, and your server's access log is too raw to be useful. An activity log fixes that. With Logify you can see every attempt's timestamp, username tried, IP, and country, get alerted the moment a spike starts, and export a clean record when you need to prove what happened.

Just be clear about the division of labour: Logify is your eyes on the login page. Pair it with strong passwords, 2FA, and a limit-login or firewall plugin to do the actual blocking, and you've got both halves of the problem covered — see what's happening, and stop it. You can start with the getting started guide or read more about the plugin at kaizencoders.com/logify.

FAQs

No. Core WordPress doesn't keep any persistent record of login attempts — successful or failed. You see a generic error on screen and nothing is stored in an admin-readable log. To track failed logins you need an activity log plugin like Logify.

Yes. Logify records the source IP for each login attempt and maps it to a location, so you can see both the IP and the country alongside the username that was tried and the timestamp.

Will Logify block attackers?

No — and it doesn't claim to. Logify is the visibility and auditing layer: it shows you who's attacking and gives you the records. For active blocking, pair it with two-factor authentication and a limit-login or firewall plugin, and block the worst IPs at your host or WAF.

Can I get alerted when there's a spike in failed logins?

Yes. Logify PRO's real-time notifications can fire on failed-login activity to email, Slack, a webhook, or syslog, with a rate limit so a burst doesn't flood you. The scheduled email digest also includes a brute-force burst count for the period.

Logify stores login events in your own WordPress database according to the retention you set, so you control how far back the history goes. For long-term records, export the relevant events to PDF, CSV, or JSON and keep them outside the database.

Why failed login attempts matter