IOS's ability to verify route availability is fairly mundane. There are features in the works to add the ability to verify routes actively (e.g., via ping), but they're currently restricted to very specific code releases on lower-end platforms (the 1700 series).
This isn't the easiest thing in the world to explain, but as it stands, IOS only knows a route has become unavailable when the route to its next-hop is removed from the routing table. The typical case is when route A points to a next-hop that is reachable via a point-to-point serial interface such as a T1. When the T1 goes down, the serial interface changes state to "down", so the connected route for that interface (i.e., the route to route A's next-hop) is removed. IOS then knows that route A is unavailable because its next-hop is unreachable, and therefore removes route A from the routing table.
The problem comes when we start to talk about Ethernet links, which sounds like what you'll be using in your case. An Ethernet link doesn't change state to "down" unless the cable is unplugged on either the local or remote side. In your case, this is fine if router-1 is directly connected to router-3 via a cross-over cable. If router-1 goes down, the Ethernet link goes down and router-3 is therefore able to detect the failure. But usually this isn't the way things are connected -- usually there are switches in between that keep the Ethernet link "up" regardless of whether or not any given router on the link is up. So in your example, if the 3 routers are connected via one or more switches, router-3 has no way of knowing when router-1 or router-2 go down unless it is running a routing protocol with them. If router-1 goes down, the route on router-3 that goes through router-1 remains in the routing table because the (connected) route to its next-hop (router-1) still exists: the Ethernet link is still up.
So this is why floating static routes tend to work fine for serial links, but are almost always useless over Ethernet links.
