Typically Fail2ban bans specific IP-addresses based on malicious patterns in your application log files. Usually fail2ban blocks the offending IP-address by generating a (temporary) firewall rule and logs only that.
When the offending IP-address has been banned those IP-addresses can't reach your application any more and no more events from those IP-addresses wil be found in the application log files. So from those log files you can't learn if the offending IP-address has backed off, or not and is still banging against the firewall .
You can try to look at the current firewall statistics to see if the latter is happening. Your mileage there may vary:
On a host with banaction = firewallcmd-ipset
there is only a rule and single counter for all blocked IP's:
iptables -L -n -v
...
pkts bytes target prot opt in out source destination
6578 392K REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 match-set f2b-sshd src reject-with icmp-port-unreachable
That makes it impossible to attribute which blocked IP-address(es) in the f2b-sshd
ipset are the repeat offenders.
On a host where each blocked IP gets effected by their own rule I see for example:
Chain fail2ban-SSH (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 117.239.37.150 0.0.0.0/0 reject-with icmp-port-unreachable
2 4 412 REJECT all -- * * 117.253.208.237 0.0.0.0/0 reject-with icmp-port-unreachable
There for example the IP-address 117.253.208.237
sent 4 packets that got logged by the firewall after having been blocked and 117.239.37.150
completely backed off.
As the other answer mentioned, you can instruct fail2ban to create a firewall rule that generates log events, which you can then post-process to get similar insights, but that isn't something fail2ban will natively process and report on.