Octet

Say this first

Tie the primary static to an object that tests the path. An IP SLA ICMP probe pings a target through the primary ISP, a track object follows the probe result, and the static has track 1 on it. When the probe fails the route is removed and the floating static with the higher AD takes over. Probe something beyond the ISP's first hop and pin the probe to the primary path with a /32.

Go deeper

Configuration

Cisco IOS

ip sla 1
 icmp-echo 192.0.2.53 source-interface GigabitEthernet0/0/0
 frequency 5
ip sla schedule 1 life forever start-time now
!
track 1 ip sla 1 reachability
 delay down 10 up 30
!
ip route 192.0.2.53 255.255.255.255 GigabitEthernet0/0/0 203.0.113.1
ip route 192.0.2.53 255.255.255.255 Null0 254
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1 name ISP1
ip route 0.0.0.0 0.0.0.0 198.51.100.1 250 name ISP2-BACKUP

The probe pings 192.0.2.53 every 5 seconds (the default frequency is 60).
delay down 10 up 30 waits 10 seconds of failure before failing over and 30 seconds of success before failing back, so a lossy link does not flap the default route.
The /32 makes the probe always use ISP1. Without it, after failover the probe would follow the backup default, succeed, bring the primary back, fail again, and flap.
The Null0 /32 at AD 254 covers the case where Gi0/0/0 itself goes down and the first /32 disappears: the probe is discarded instead of leaking out ISP2.

Checking it

Output

R1# show track 1
Track 1
  IP SLA 1 reachability
  Reachability is Up
    1 change, last change 02:11:40
  Delay up 30 secs, down 10 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 6
  Tracked by:
    Static IP Routing 0

After a failure, Reachability is Down and show ip route shows S* 0.0.0.0/0 [250/0] via 198.51.100.1.

Choosing the target

Pinging the ISP gateway only proves the first hop. A target deeper in the ISP or a well-run public resolver tests more of the path, but if that one host goes down you fail over for nothing. Some designs use two probes combined with a boolean track (track 3 list boolean or).

They will ask next

What else breaks during a dual ISP failover?
NAT. Each ISP needs its own NAT rule, usually ip nat inside source route-map with a route-map that matches the outgoing interface, so traffic is translated to the right ISP's address after failover.
Junos and Linux?
Junos static routes use qualified-next-hop with a higher preference for the backup, and SRX uses RPM probes with ip-monitoring for tracking. On Linux you give two default routes different metrics, but the kernel only removes one when its link goes down, so a probe daemon is needed for real tracking.

Traps

Forgetting the /32 for the probe target. It is the most common cause of a flapping failover.
Forgetting ip sla schedule. An unscheduled probe never runs and the track stays down from the start.
Fixing only one side. The far end, or the ISP, also needs a way to send return traffic over the backup.

How did you do?Book 3.3 Internet (IP)