# fail2ban log analyzer

> Paste auth.log, secure, journalctl or nginx/Apache logs and see attacking IPs, failures per hour, usernames tried and which IPs fail2ban would ban. Runs locally.
>
> Source: https://fail2ban.dev/tools/log-analyzer/ · Updated 2026-10-25 · Checked against fail2ban 1.1.1
> fail2ban.dev is an independent guide, not the official fail2ban project.

## Get a log to analyse

Copy a chunk of the log from your server and paste it above, or save it to a file and open it. A few hours to a few days of log is plenty.

```bash
sudo tail -n 20000 /var/log/auth.log > ~/auth-sample.log     # Debian/Ubuntu
sudo tail -n 20000 /var/log/secure > ~/auth-sample.log       # RHEL/Rocky/Alma

# SSH on journal-only systems (Debian 12+, Ubuntu 24.04 with backend = systemd)
sudo journalctl -u ssh -u sshd --since "24 hours ago" -o short > ~/auth-sample.log

# nginx
sudo tail -n 50000 /var/log/nginx/access.log /var/log/nginx/error.log > ~/web-sample.log
```

> **Your logs stay on your machine**
The analysis runs entirely in your browser — the page downloads the filter definitions once and never sends your log anywhere. You can disconnect from the network after the page has loaded and it still works.

## What the analyzer does

1. **Detects the log type** by trying 40 of fail2ban's most common built-in filters (sshd, nginx, Apache, Postfix, Dovecot, FTP servers, Proxmox, Vaultwarden and more) on the first few thousand lines.
2. **Runs the matching filters** over every line exactly like fail2ban: it removes the timestamp, applies `prefregex`, `failregex` and `ignoreregex`, and extracts the address and user name. This is the same engine as the [regex tester](/tools/regex-tester/).
3. **Simulates the jail.** For each address it slides a `findtime` window over the failures and counts a ban whenever `maxretry` failures fall inside it — then starts counting again, as fail2ban does after a ban.

The result tells you which jails are worth enabling, how aggressive your `maxretry` and `findtime` need to be, and whether one address is responsible for most of the noise. Turn the findings into a config with the [jail.local generator](/tools/jail-generator/).

## Reading the results

- **Failures found** — lines that a filter treats as an authentication failure or attack. Successful logins are ignored.
- **Would be banned** — addresses that reach `maxretry` failures within `findtime` at least once. Change the two values in the toolbar to see the effect immediately.
- **Usernames tried** — from filters that capture `<F-USER>`. Names like `root`, `admin`, `oracle` and `test` are the classic signature of automated scans; your real user names appearing here is a reason to check where the attempts come from.
- **Failures per hour** — bursts often line up with a single botnet campaign.

If the analyzer finds nothing in a log you know is full of failures, the service probably logs in a format no built-in filter covers — build one with the [filter generator](/tools/filter-generator/).

## FAQ

### How do I see failed SSH login attempts on Linux?

Run `sudo grep "Failed password" /var/log/auth.log` (or `/var/log/secure` on RHEL), or on journal-only systems `sudo journalctl -u ssh --since today | grep -i failed`. Paste the output into the analyzer to group it by IP and see which addresses fail2ban would ban.

### Which IPs would fail2ban ban from my log?

The analyzer answers exactly that: it applies the built-in filters and simulates `maxretry` within `findtime` for each address. Set the two values to match your `jail.local` (the stock defaults are 5 and 10m).

### Is it safe to paste my server logs here?

Yes — nothing is uploaded. The page runs the filters in JavaScript on your computer. Logs can still contain usernames and internal addresses, so treat any copy you save or share with care.

### Can it read compressed logs like auth.log.2.gz?

Not directly. Decompress first with `zcat /var/log/auth.log.2.gz > auth-old.log`, then open or paste the text.