It will happen. A router reboots, the building's line hiccups, someone unplugs the wrong thing in the office while looking for a socket. The question is not whether you can prevent it — you cannot — but what the room experiences when it does, and whether anybody notices in time to act.
What recovers on its own
A listener's phone that loses connection does not need anyone's help. The page notices the stream has gone quiet, reconnects itself, and picks up from the live edge. From the seat this looks like a pause and then words again, and most people assume the speaker stopped for a moment.
What a listener will not get back is the sentence spoken during the gap. Live means live. This is worth saying out loud to your team so nobody spends an afternoon looking for a bug that is actually the definition of the thing.
Phones dropping out individually — one person's mobile signal, someone walking into the stone corner of the building — are not your problem and do not need managing. They come back.
What needs a human
The broadcasting device is the one that matters: the laptop or phone at the desk sending the audio. If that loses connection for a long stretch, nobody in the room knows. The speaker carries on, the congregation carries on, and the only people aware of it are the ones reading a page that has stopped moving — and they will assume it is their phone.
This is the entire reason the operator's screen shows the live text, and the entire reason not to walk away from it. One habit covers it: if the speaker is talking and the text is not moving, something is wrong.
How to tell what kind of failure it is
Two failures look identical from the desk and have different fixes. Spend ten seconds distinguishing them before doing anything.
- The text stopped completely. Connection, or the microphone is off, or the channel is muted. Check the microphone first — it is more often that than the network — then restart the broadcast.
- The text is moving but reads as nonsense. Not a network problem at all. That is audio: the feed has gone quiet, a battery is fading, or something was unplugged at the desk. Restarting will not help and the fix is upstream.
Teaching the difference takes a minute and saves an operator from restarting a broadcast four times during a sermon while the actual problem is a dead radio microphone.
Three preparations that turn it into a non-event
- A phone hotspot, already tested. Not "someone has a phone" — actually paired once, in advance, with the password saved on the broadcasting device, so switching over is a tap rather than a support call in front of a congregation.
- Wired, not wireless, for the broadcasting device. A cable removes the single most common failure in the chain and costs the price of a cable.
- A second person who knows the three buttons. If the operator is the only one who understands the screen, every outage waits for them to come back from the coffee table.
The part you are actually paying for
If usage is metered by the hour, an outage is not a billing problem either — a stopped broadcast is not billed. Worth knowing, because the instinct in the moment is to leave everything running while somebody investigates, and that instinct is fine.
The same is true of pausing deliberately. If the service moves to something that should not be translated, pausing costs nothing and keeps the archive clean.
Tell people in advance
The difference between a congregation that shrugs at a ten-second gap and one that concludes "this does not work" is almost entirely what they were told to expect.
One line in the welcome — "if it pauses, it will come back on its own" — buys enormous patience. Without it, the first outage becomes the story, and people who had a poor first experience do not come back for a second.
The same applies to your leadership. If the pastor knows that a brief gap is normal and self-correcting, they will not stop mid-sentence to ask whether it is working, which is a far worse interruption than the outage.
Practise the failure once
During a quiet weekday test, pull the cable on purpose and watch what everyone's screen does. Then plug it back in and watch the recovery.
Ten minutes of doing this deliberately is worth more than any amount of reassurance, because your operator will have seen the thing happen once in a room where it did not matter. It is exactly the kind of thing to fold into training a volunteer to run it.
What not to do
- Do not announce it from the front. "Sorry, the translation has stopped" tells two hundred people about a problem affecting six, and makes it look fragile.
- Do not restart repeatedly. If one restart does not fix it, the problem is not the thing you are restarting.
- Do not troubleshoot during the sermon. Note it, carry on, and fix it in the week. Nothing you discover mid-service is worth the distraction.
- Do not blame the platform in front of the congregation before you have checked the microphone. It is usually the microphone.
Set it up to be boring
InMyTongue reconnects listeners automatically and stops the clock when a broadcast stops, so an outage costs you a sentence and nothing else. See how a service runs end to end.