Troubleshooting transcription latency

This guide is for situations where transcript text arrives noticeably later than speech. Use it when delay starts affecting facilitation timing and decision tracking.

Quick path:

1. Decide whether latency is local (one table) or systemic (many tables).
2. Run the matching action path immediately.
3. Check whether delay improves within 2-3 minutes.
4. If not, escalate with a clear incident log.

Classify the symptom first

Local latency usually appears on one table while others remain normal. Systemic latency appears across multiple tables at once. This split determines the correct troubleshooting path.

If you mix the two paths, recovery gets slower and room communication gets messy.

Path A: one table affected

Focus on device and local conditions:

• verify microphone permission and active connection
• keep the phone stable near table speakers
• reconnect if flow does not return

If delay persists, move to [Replacing a phone mid-session](/guides/setup/replacing-a-phone-mid-session).

Path B: multiple tables affected

Treat this as infrastructure behavior, not table behavior:

• verify network stability in the room
• reduce simultaneous disruption (for example, mass reconnections)
• run [Workshop infrastructure reliability checklist](/guides/advanced/workshop-infrastructure-reliability-checklist)

If spikes coincide with frequent reconnects, check [Device reconnection behavior](/guides/advanced/device-reconnection-behavior).

Live communication while fixing

Use short facilitator language: "Text is delayed right now, keep speaking at normal pace while we restore flow." This prevents tables from switching into unnatural stop-start speech, which usually makes quality worse.

Once flow returns, ask affected tables to restate the latest decision in one sentence to close any gap.

When to escalate

Escalate when:

• latency persists after targeted actions for several minutes
• multiple tables remain affected in waves
• latency appears together with ordering drift on decision points

Log timestamp, scope, and actions already tested. That gives usable escalation data instead of a vague "it was slow" report.

Related guides

• [Device reconnection behavior](/guides/advanced/device-reconnection-behavior)
• [Why transcript ordering matters](/guides/advanced/why-transcript-ordering-matters)
• [Workshop infrastructure reliability checklist](/guides/advanced/workshop-infrastructure-reliability-checklist)
• [Reconnecting a disconnected device](/guides/setup/reconnecting-a-disconnected-device)
• [Replacing a phone mid-session](/guides/setup/replacing-a-phone-mid-session)