Pre-market readiness is not a single green dashboard. It is a chain of assumptions across connectivity, routing, market data, time, hosts, security, vendors, and recovery. The checklist should verify that chain.
1. Confirm the real production path
Verify the active and standby circuit, routed path, firewall member, switch pair, and colocation cross-connect. A diagram is useful, but live forwarding state is the truth. Compare it with the intended path and investigate unexpected asymmetry.
2. Validate multicast health
Review PIM and IGMP state, receiver membership, interface counters, drops, errors, and recent topology changes. Confirm the feed is present where expected without flooding segments where it is not needed.
3. Check route stability and failover state
Inspect BGP and IGP neighbors, accepted and advertised routes, policy changes, route age, next hops, and redundant paths. A backup route that exists in configuration but has not been exercised is only a theory.
4. Verify time and event correlation
Confirm the authoritative time source, client synchronization state, offset, drift, and monitoring thresholds. Network, operating system, application, and security records must support one defensible event timeline.
5. Look at capacity and errors, not only availability
An interface can be up while queues, discards, optical levels, CPU, memory, storage latency, or packet loss are already moving in the wrong direction. Baseline the signals that normally precede degradation.
6. Reconcile overnight change
Know every change completed or still in progress, its validation result, its rollback state, and the person who owns any exception. Include carrier, venue, cloud, security, and facilities work, not just internal tickets.
7. Confirm escalation and vendor reachability
Test the contact path for carriers, colocation providers, market-data vendors, exchanges, hardware support, and application owners. Store circuit IDs, device serials, contract details, and authorization contacts where the responder can reach them.
8. Make recovery specific
Define the trigger, decision owner, route or site change, application sequence, user communication, validation, and fallback. Recovery should state what happens first, what proves success, and when to stop.
If the primary path fails five minutes before the open, can the team explain exactly what changes, who approves it, how long it should take, and how success will be measured?
Turn the checklist into an operating rhythm
Assign each check an owner, data source, expected result, exception path, and retention period. Automate collection where it improves consistency, but keep an engineer responsible for interpreting changes and business impact.