The Xbox channel recorded "failed · node exited 1" whenever the devkit was switched off, which in a receipt somebody reads later is indistinguishable from a console that rejected the build. One of those is a problem and the other is a console in a cupboard, and the release could not tell you which. It also took seventy-five seconds to not tell you: `live.mjs` curls the Device Portal and curl wears its whole connect timeout discovering there is nothing at the other end, every deploy, after the web channel has already gone out. So the release asks first. A plain TCP connect with a two-second fuse, to the host read from the same env file `live.mjs` reads, so the release and the transport can never disagree about which box they mean. Unreachable is its own channel status — `offline`, with the reason — and the deploy is skipped rather than attempted and mourned. A machine with no Device Portal configured at all answers the same way, because it is the same answer: not here, not broken. `parity` is unchanged and still means every channel current, because an offline console genuinely has not got the build and a receipt that said otherwise would be lying. What is new is that the run can say the difference out loud: `blocked` is the channels that actually went wrong, and an empty `blocked` alongside a non-empty `offline` prints "Nothing failed." `deploy-xbox-dev` still throws, because asking for the Xbox explicitly and finding it asleep is a failure of what you asked for — there is no other channel there to succeed. It just says which of the two happened now. A deploy against the sleeping devkit went from 75s to 2.7s. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>