**Parent Topic**: [[Software/README]] 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. 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. ## Source *Source: [[Site Reliability Engineering]] (Beyer et al., O'Reilly 2016) — Ch 32 — The Evolving SRE Engagement Model*