Working template

Internet failover test record

A companion to How to test internet failover and know what passed.

Download the text file to fill it in with your own details, or print a blank copy.

Complete the plan before creating the failure condition. This form records a bounded test; it does not establish resilience against untested scenarios.

Plan

Test lead / authorization:  

Window / timezone:   Stop authority:  

Test type: walkthrough of the procedure only / controlled failover in a maintenance window / unannounced failover during business hours

Failure scenario (for example, primary circuit down, primary router down, upstream DNS failure, both circuits up but degraded):  

Primary / alternate path, including the device that decides to switch:  

Expected switch time and expected switch-back behavior:  

People notified in advance and how:  

Abort criteria (what observation ends the test early):  

Communication and restoration instructions:  

Baseline before the failure

  • [ ] Both paths confirmed up and carrying expected traffic.
  • [ ] Public address of each path recorded; services that allowlist the office address are listed.
  • [ ] Voice, video, VPN, and printing confirmed working on the primary path.
  • [ ] Monitoring is watching both paths and someone is watching the monitoring.
  • [ ] Alternate path capacity, data cap, and contract terms are known.

Observations

Workflow / session type Expected interruption limit Expected degraded behavior Observed result / timestamps Pass, fail, or untested
Sign-in, new session
Document access
Call, existing session
Call, new session
VPN or remote access
Site-to-site or cloud tunnel
Service that allowlists the office address
Other critical workflow

Time to detect / time to switch / time to first user report:  

Failback

Step Expected Observed / time Exception
Primary path restored
Traffic returns to primary
Sessions and tunnels re-established
Alerts cleared

Restoration checks

  • [ ] Intended primary and alternate states are confirmed.
  • [ ] Application checks are repeated after restoration.
  • [ ] Temporary changes are removed.
  • [ ] Remaining alerts and interrupted sessions are accounted for.
  • [ ] Findings are shared with the people who were affected.

Actual interruption:  

Untested dependencies / assumptions:  

Exception Owner Action Retest condition / date

Common failure modes

  • The alternate path works but the address change breaks services that allowlisted the primary.
  • Failover succeeds and failback does not, leaving the office on a metered or slower path.
  • Existing calls survive while new sign-ins fail, so the test looks better than it is.
  • Nobody records the time, so the result cannot be compared to the last test.

Test conclusion and acceptance:  

Next test date / trigger (circuit change, router replacement, provider change, office move):  

This record covers the office internet path. It does not establish that cloud services, identity, or remote workers would survive their own failures.