Interruptions are normal, not exceptional
A meaningful share of live chats do not end because someone said goodbye. They end because a train went into a tunnel, a laptop slept, a phone switched from wifi to cellular, or somebody closed the tab to check the order number they were being asked for. None of that is a fault in your support process, and none of it is rare.
Most teams have no plan for it. They have a plan for busy periods, a plan for angry customers and a plan for after hours, but the interrupted conversation is treated as an anomaly — so the agent handles it improvisationally, the visitor comes back to something confusing, and a chat that was going fine ends in a repeat contact.
It is worth planning for, because the recovery is cheap and the failure is expensive. A visitor who returns to find their conversation intact usually carries on mid-sentence. A visitor who returns to an empty box concludes that they have to start again, and a good number of them simply do not.
What actually happens when the connection drops
It helps to know the mechanics, because they determine what you should say. When the visitor's connection fails mid-conversation, the widget does not immediately give up and it does not silently pretend everything is fine. It detects that the channel is no longer delivering, shows the visitor that it is working on it, and retries the connection on a short delay for a small number of attempts before it concedes.
While that is happening the visitor sees a status message — Restoring your chat... — rather than a dead window. If the reconnect succeeds, the conversation is re-established and the transcript is replayed so the visitor is looking at the same conversation they had a moment ago, with duplicate messages suppressed rather than pasted in twice.
Two things follow from this. First, a brief silence from the visitor is often the network, not indifference — and the agent has no way to tell those apart from the outside. Second, when the visitor returns they are not starting from nothing, so an agent who greets them as a brand new conversation is contradicting what the visitor can see on their own screen.
What the visitor keeps, and for how long
The recovery is not limited to a connection blip. The widget keeps enough state to rebuild the conversation after the page itself has gone away — a refresh, a navigation to another page, or closing the tab and coming back later.
- The conversation, for eight hours. The resume window is generous by design: a visitor who wanders off after lunch and comes back can still pick up the same conversation rather than open a second one.
- The recent transcript, up to a cap of the most recent messages, so a long conversation returns with its context rather than a stub.
- A half-typed message. The composer draft survives, which matters more than it sounds — the most annoying moment to lose a chat is three sentences into explaining the problem.
- Whether the window was open, so a visitor who had the chat open does not have to find and reopen it.
- A resume prompt rather than an ambush: the returning visitor is offered their existing conversation instead of being dropped into it.
Two safety properties are worth knowing because they occasionally explain a support question. The stored state is timestamped and is rejected once it is stale, so a conversation does not rise from the dead a week later. And it is isolated per account, so a visitor who uses two different sites that both run MyLiveChat cannot have one site's conversation resume inside the other's widget.
If you want the paper trail rather than the visitor-side copy, that lives in your chat transcripts, which is also where you go to reconstruct what a returning visitor was told the first time.
What the agent sees, and the mistake to avoid
From the agent's side an interruption looks exactly like a visitor who has stopped typing. That ambiguity is the whole problem, and it produces two opposite errors.
The first is closing too fast. An agent who treats thirty seconds of silence as a finished conversation ends chats out from under people who are in a lift. The second is waiting forever, which quietly consumes a concurrency slot that a waiting visitor needs.
The rule that works: before you close, say what happens next, and make it true. A closing line that says the transcript will be emailed, or that the conversation can be resumed, or that a reply will follow by email, converts an interruption from a dead end into a handoff. A closing line that just says Closing due to inactivity tells the visitor they have been given up on.
Writing for the moment it comes back
The reconnect is a small writing problem and most teams get it wrong by over-explaining. The visitor does not want a narrative about your infrastructure; they want to know whether they have to repeat themselves.
- Acknowledge without diagnosing. Looks like that dropped for a second — I still have everything you sent. That single clause answers the only question they have.
- Never make them repeat what you can see. If the transcript came back, use it. Asking a returning visitor to restate their order number when it is four lines above is the fastest way to make the recovery feel worthless.
- Restate the last thing you asked, because that is the one thing they may genuinely have missed.
- Do not apologise three times. One acknowledgement, then continue. Repeated apology reads as though something serious went wrong.
- If it drops repeatedly, move channel deliberately rather than fighting it: offer to continue by email and say why.
Put those four lines in your canned responses so nobody has to compose them under pressure. This is exactly the kind of moment where a saved phrase beats improvisation.
When the interruption is not technical
Not every silence is a network. Visitors get called away, put the chat aside to find a document, or decide mid-conversation that they would rather not continue. Treating all of those as connection failures leads to agents chasing people who have simply left.
You usually can tell the difference by shape. A network interruption tends to cut off mid-exchange, often mid-answer, with no change in tone. A visitor who has disengaged usually slows down first — shorter replies, longer gaps, then nothing. The second pattern deserves a different response: one useful message that stands on its own and does not require them to come back.
That message is worth writing carefully, because it is the last thing they will read. Give the answer if you have it, say how to reach you, and stop. Do not ask a question, because a question that nobody answers leaves the conversation feeling unfinished for both sides.
One honest caveat, because it changes what you can promise. The resume-and-restore behaviour described above belongs to the current generation of the chat widget. Installations still running an older generation reconnect differently and do not carry the same resume window, transcript replay or preserved draft.
Older installations are never converted underneath you — moving generation is a deliberate change you make — so if any of this matters to your team, the first step is to find out what you are actually running rather than assuming. Our guide on which widget version you are running covers how to check.
This is also the reason to test the behaviour on your own site rather than trusting a description, including this one. Open a chat, send two messages, put your phone into airplane mode for ten seconds, and watch what comes back.
What to measure
- Conversations that resume, as a share of conversations that go quiet. If it is near zero, either your visitors are not coming back or something in your setup is discarding the state.
- Repeat contacts within an hour from the same visitor, which is the signature of a recovery that failed and a customer who started over.
- Chats closed for inactivity that later reopen, which tells you your inactivity timeout is shorter than your visitors' attention.
- Time from reconnect to the next agent message. A returning visitor waiting again is the worst version of this experience.
- Whether the drop clusters, by page or by device. Interruptions concentrated on one page are a page problem, not a network one.