# Internet failover test record

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.