iRule HTTP_RESPONSE event not kicking in

That is exactly as expected. Both HTTP events are triggered after the headers are consumed. So HTTP_REQUEST fires after the client request headers are received, and HTTP_RESPONSE fires after the server response headers are received. No response, no event.

Kevin, thanks for the clarification.

Then my next questions is, is there an event to track when the server does not send the headers?

Bottom line is I want to identify when server does not respond so that I can send user to an alternative page.

Best practice is going to be an intelligent health monitor applied to the pool so this doesn't happen. There's always the possibility that a server can fail between monitor "pings", but to detect that might be more work than just letting the monitor remove the server from the pool.

Sure, we have monitors in place to take out the member from the pool.

And if the entire Pool is down then I have when LB_FAILED event as well.

But the need for me to perform this from an iRule is still there, such that if https://mydomain/mysite/mypage.aspx does not respond, then I want to send to https://myotherdomain/mysite/mypage.aspx.

Please advise.

But the need for me to perform this from an iRule is still there, such that if https://mydomain/mysite/mypage.aspx does not respond, then I want to send to https://myotherdomain/mysite/mypage.aspx.

after wiki (More Examples: send response from BigIP if server does not respond within a specified amount of time)

But the need for me to perform this from an iRule is still there, such that if https://mydomain/mysite/mypage.aspx does not respond, then I want to send to https://myotherdomain/mysite/mypage.aspx.

after wiki (More Examples: send response from BigIP if server does not respond within a specified amount of time)

While it's certainly a workable idea, I'd hesitate to use the after command, given that it has the potential to consume extra memory and that you'd be using it on every HTTP response. I think you might do well here with an inband monitor and an iRule like this:

when CLIENT_ACCEPTED {
    set def_pool [LB::server pool]
    set lb_fails 0
}
when LB_FAILED {
    log local0. "lb failed"
    if { $lb_fails < [active_members $def_pool] } {
        LB::mode rr
        LB::reselect pool $def_pool
    } else {
        log local0. "no servers available"
        HTTP::redirect "http://www.google.com"
    }
    incr lb_fails
}

You'd normally combine this with an active monitor that proactively removes failed members from the pool, while the inband monitor and iRule waits some predetermined amount of time for a response before triggering an LB_FAILED event.