A five-minute runbook for live translation failure

The worst response to a translation incident is stopping the host while host and operator explore settings together. Viewers lose both translation and the original show.

This runbook does not promise to repair every fault in five minutes. It forces a decision inside a fixed time box: continue recovery, degrade translation, or preserve the main broadcast without it.

State the viewer impact first

An operator checks from a second device:

• captions missing, speech present;
• speech missing, captions present;
• both missing;
• both present but stale or attached to the wrong product.

Do not infer this from the host’s headphones. Local monitoring can work while stream output is muted.

Use four observation points

1. Workbench text

Does ObsTrans continue producing partial, final source, and final target text?

• No source: inspect microphone, recognition route, login, or network.
• Source but no target: inspect translation errors.
• Both: the text path works; move to playback and caption outputs.

2. TTS state

Is queued count growing? Does current playback change? Text with no speech points to Playback translation, cloned voice, or output device. Speech so stale that it names the wrong product should be stopped before further diagnosis.

3. OBS meter and local recording

Does the translated-audio source move? Capture a short recording.

• Flat meter: fault between translation app and virtual cable.
• Moving meter, silent file: OBS mute, monitoring, or track.
• Good file, bad viewer stream: stream track, encoder, network, or platform.

YouTube’s official troubleshooting guide similarly starts with encoder audio/video and the local archive, then moves to outbound connectivity when the encoder is healthy.

4. Green-screen caption

Is the green window updating? Is OBS Window Capture frozen or closed? Healthy workbench text with no on-screen captions is a window/capture fault, not a reason to restart recognition.

Three fallback modes

Caption-first. TTS or cable failed while captions remain reliable. Disable translated playback, clear stale speech, slow the host, and tell viewers to follow captions.

Speech-first. The green window or OBS caption capture failed while speech remains current. Retain audio and avoid complex statements that require reading numbers.

Single-language main stream. Recognition or connectivity failed broadly. Disable translation, return to the rehearsed single-language flow, and have the operator post a fixed target-language notice.

Rehearse these modes in the preflight checklist, not for the first time in production.

Change one layer at a time

Use this order:

1. reselect a microphone or output device reset by the OS;
2. stop and restart Voice translation;
3. reopen the green window or refresh its OBS capture;
4. restart the app only if the app is unresponsive;
5. restart OBS only when the main encoder is also affected.

Restarting OBS can interrupt the entire broadcast. It is not a harmless first experiment. After each action, observe the matching checkpoint before doing another.

Verify recovery end to end

Speak a harmless test sentence without price or conditions. Confirm:

• final text appears;
• captions update;
• the TTS queue begins and completes;
• the OBS meter moves;
• a viewer phone hears and sees the same sentence.

Only then return to product facts. A price is a poor recovery test because partial recovery can publish a wrong offer.

Write an actionable review

Record timeline, last healthy checkpoint, viewer impact, actions, recovery evidence, and any lost content. Avoid “network probably bad” unless a measurement supports it.

Add reproducible failure to the tool acceptance protocol as a reconnection, endurance, or route test. The value of an incident is a faster fallback next time, not a polished narrative.