A **dark launch** is a launch-risk-reduction technique: send a portion of real traffic from existing users to the **new** service *in addition to* the live production service — but **throw away the new service's responses** ("dark"), never showing them to users. This lets the team: - Gain **operational insight** into how the new service behaves under real production traffic - **Resolve issues without impacting existing users**, since the dark responses are discarded - **Reduce the risk** of encountering problems after the real launch The value, per the chapter, is that a smooth launch keeps the operational burden low and preserves development momentum. Disruptions around launch tend to trigger emergency source-code and production changes and derail the dev team's work on future features — so de-risking the launch protects future velocity, not just launch-day stability. Dark launch complements canary/gradual rollout: a canary exposes a *small fraction of users* to *real* responses from new code, whereas a dark launch exposes the new service to *real traffic* but exposes *no users* to its responses. Dark launch validates the new path's behavior and load handling under full production conditions with zero user-facing risk.