monitor timeouts vs actual behaviour

what you're describing seems to be consistent. When things ARE happy, yes it'll poll every 5 seconds, and the member will go down after 16 if configured to do so. But you can't then bring it back up until you can poll it again, which requires the existing failing connection to stop. What things look like under the hood doesn't reflect the outward presentation of the member availability. If you rig things so that the TCP monitor goes unanswered, not reset, what do you see then? I presume you'll see the same huge huge delay. This kit has been upgraded over the years from something like 9.0.5, maybe there's some junk settings hidden away somewhere that could be changing things? I'd certainly be interested to hear more about the HTTP side of things, as that seems much more blatant a behavior to see.