The code wasn't the issue. It's am easy fix. The question was if there was a reason

I remember there was some discussion about that in past, but I don't remember when and where (issue or PR) ... but I think it might really be intended like it is. Maybe @wilsonge remembers? Or @zero-24 ?

I can't help here.

I have searched but haven't found it. Maybe I remember wrong, or maybe it was hidden in some issue or pr not directly related to the hit counter.

There are pros and cons.

A con is when counting redirect hits for a redirect which is enabled over years, the count might become very high. Maybe the count once was intended to show only how much a redirect would be needed, i.e. count the 404 only so I can see if it really needs to enable it or not.Tthis can be quickly seen with new collected urls by just ordering by the count, or descending by id and then verifying the counts. When having a counts for all redirects, maybe all with similar, high counts, it might be less easy to quickly see that.

A pro would be to see if a count did not increase anymore for a longer time for an enable redirect, then it could be removed maybe. But it would be easier to see that if it was possible to reset the counter so I can see after a while if it is still zero, then the redirect could be removed, instead of having to compare with an old counter value to see if it has changed or not.

I am not sure what is better, count only the 404 like now, or always count.

But especially if always count it would be good to have a way to reset the counter without having to use PhpMadmin or similar tools. Maybe it could always be reset when status changes from disabled to enabled or vice versa?

A pro would be to see if a count did not increase anymore for a longer time for an enable redirect, then it could be removed maybe.

Thats why I was looking at this in the first place with a view to updating the modified date each time it was "hit" and thats when I discovered the issue