Just to expand on my post above:
To make this work you won't really be able to trace to the final host, cause once the track fails and the new route is injected, if over the new route latency is below 500ms the track would show as good to final host and original route would be injected back into the routing table again, and you can see this would just start causing the track to fail up and down like a yo-yo.
What you could do is hard route either the first or last hop along the path of one route, and the first or last hop along the other route before the final host and check for latency right before it gets to the final destination and monitor that SLA and fail.
For example:
Final host is 10.10.10.10
over preferred route:
traceroute 10.10.10.10
reply from 10.1.1.1
reply from 10.1.2.1
reply from 10.1.3.1
We're going to say that 10.1.3.1 was the final hop before it reached host 10.10.10.10 over your preferred link
So we'll create that static route
ip route 10.1.3.1 255.255.255.255 10.1.1.1
Now that we know 10.1.3.1 will only route out the preferred gateway we can create the monitor
ip sla monitor 10
type echo protocol ipicmpecho 10.1.3.1
frequency 5
timeout 500
ip sla monitor schedule 10 life forever start-time now
now the monitoring has begun..but we need to setup a track for that sla
so we'll create track 10 to track sla monitor 10:
track 10 rtr 10 reachability
That track will test sla monitor 10 and if it fails, we'll use it to change the routing table.
So our preferred route to 10.10.10.10 is 10.1.1.1 so we'll add a tracked route for that using the SLA monitor and track above
ip route 10.10.10.10 255.255.255.255 10.1.1.1 1 track 10
Metric for this route is 1 and as long as track 10 is up it will be injected.
Our secondary route to 10.10.10.10 is through 10.1.1.2 we'll just add a higher metric route for this path that will only be used if track 10 fails and the above route is removed from the table:
ip route 10.10.10.10 255.255.255.255 10.1.1.2 10
So as long as latency to 10.1.3.1 which is the last hop we can ping before the 10.10.10.10 host is less than 500ms track 10 will be up and 10.1.1.1 will be the gateway we use to get to that ip. If latency to 10.1.3.1 goes above 500ms it will fail to 10.1.1.2. As soon as latency to 10.1.3.1 falls below 500ms and the track shows as up again, the lower metric route will be injected back into the table and the router will start sending traffic to 10.10.10.10 through the preferred gateway.
