Quick answerA planned maintenance window is different from an outage in one crucial way: you control when it starts, so you can choose not to start it while conversations are in flight. Route new conversations away from the window before it begins, give any conversation already in progress a defined grace period to reach a natural stopping point, and only force-suspend the small remainder that's still active when the grace period ends — with an explicit resume path so the customer doesn't have to restart from zero. Because this is scheduled and controllable, the bar for customer experience during it should be meaningfully higher than during an unplanned failure.
Why treating this like an outage response wastes the advantage of planning it
Regional infrastructure failover during a cloud outage and setting a realistic recovery-time expectation once an outage ends are both about responding well to something you didn't choose and couldn't fully predict. A maintenance window is the opposite: you picked the time, you know the duration, and you can shape traffic around it in advance. Treating a planned deployment with the same reactive posture as an unplanned failure — waiting for conversations to break, then scrambling to communicate — throws away the entire advantage of knowing about it beforehand.
Stage the traffic before the window opens, not during it
Fifteen to thirty minutes before a maintenance window (longer if your typical conversation length runs longer), stop routing new conversations to the component being taken down, and route them either to a lighter-weight fallback mode or to a clear "starting shortly" message with an accurate time estimate. This alone eliminates the worst version of the problem: a customer starting a multi-step conversation two minutes before the window opens and getting cut off mid-task. It's a much smaller, more manageable population — those already active when staging began — that the rest of the runbook has to handle.
Give in-flight conversations a real grace period, and mean it
For conversations already active when the window's staging period starts, don't force an immediate stop. Give them a defined grace period (long enough to reasonably finish a typical conversation, short enough not to meaningfully delay the maintenance) to reach a natural end. Track how many conversations are still active as the grace period closes — this number tells you whether your estimate of a "typical" conversation length is realistic, and it should get better over successive maintenance windows, not stay flat.
For the remainder, suspend with a resume path, not a dead end
Whatever's still active when the grace period actually ends needs to be suspended in a way the customer can pick back up, not silently dropped. Persist conversation state (what's been discussed, what step they were on) so that when the window closes, the customer can either resume automatically or is told clearly where things left off rather than having to re-explain everything from scratch. This mirrors the discipline behind canary rollouts, where customers in the test group are owed an easy, working path back to standard behavior if something goes wrong — a controlled, scheduled event still owes the customer a clean way back in, precisely because you had the chance to build one in advance.
FAQ
Should customers be told in advance that a maintenance window is coming? For anything beyond a very short window, yes — proactive notice for anyone likely to be actively using the agent during that time, even if it's just a banner or a status page update, costs little and avoids the worst customer reaction: being cut off with zero warning during something they didn't know was scheduled.
How long should the grace period be? Long enough to cover your typical conversation length at a high percentile (not the median), so you're not routinely forcing a stop on conversations that are simply running a bit longer than average. Measure your own conversation-length distribution rather than guessing.
What if the maintenance window runs long? Have a defined extension protocol before you need it: a hard cutoff for how long you'll silently extend before proactively notifying customers still waiting, and a fallback (like temporary human routing) if the window materially overruns its estimate.
Does this apply to background agent tasks too, not just live chat? Yes — any in-progress background action the agent initiated (a multi-step workflow, a queued follow-up) needs the same grace-period-then-safe-suspend treatment as an open conversation, since an abandoned half-completed background task can cause more downstream damage than a paused chat.