Compute Failover Reference Document

published Last Updated: Oct 9, 2026 HW: all

General information

Preflight and Dock ASAP

Compute B (the secondary controller) and various services running on it are part of the critical flight path. This means that conditions on Compute B can cause preflight to fail and may trigger a Dock ASAP.

For information about identifying whether Compute A or Compute B is affected, see Determine Impacted Compute.

Failover

Various conditions that previously caused a Paraland will now trigger a failover to Compute B. Compute B will then abandon the mission, execute a Dock ASAP, and bring the Zip back to its destination dock.

At a high level there are two kinds of failover missions:

Compute B is in control, Compute A is dead/not communicative
- In this situation, the cloud and fleet apps will not have any information about the status or location of the Zip since Compute B does not have cloud comms support.
- Apps will only know the state or position of the Zip when Compute A comes back online or the Zip returns and docks.
- Operators will not be able to send any commands to the Zip.
Compute B is in control, Compute A is running and aware of the failover
- Here cloud and fleet apps should contain a banner indicating that a failover has occurred.
- Some data from the Zip, such as LLA position and wind estimation, will be accurate (sent from Compute B → Compute A → cloud), but most of the data about Zip status is not reliable.
- Operators can only command a Paraland in this situation, and they should only do this when absolutely necessary. Pause and Dock ASAP commands will not be honored by the Zip.