How do I even notice that the assistant is running in a restricted state?

Through your own measurements, not through complaints. For every request the assistant records how long the knowledge base, the language model and the connected systems took, and it writes each limit exceeded into a log with stage and system. Those entries add up to a simple view: how many conversations ran in stage 0 today, how many in stage 2 or higher. When the share of higher stages rises, you know about the disturbance before the first complaint arrives. An external check that asks a standard question at short intervals and records the response time is a useful addition.

Would it not be better to hide the chat entirely during a disturbance?

Usually not. A vanished widget answers no question and additionally takes away the route the visitor was about to use. The more sensible option is the stage in which the chat only takes in enquiries: it says in one sentence what is missing, offers a form and a callback and confirms receipt with a time frame. The assistant is only hidden when delivery of the widget itself is affected. For that case, contact route and form belong permanently in the page anyway, independent of the chat.

What availability is realistic for a chat assistant?

Instead of a number in a contract, an honest calculation helps. BSI Standard 200-4 states 8.76 hours of permitted downtime per year for 99.9 percent, and around 87 hours for 99 percent. What matters is what happens during those hours: an assistant with fallback stages keeps taking in enquiries during that time, one without loses them. That is why we record in the operating concept how long each stage is acceptable, and then measure how often each stage was actually active.

How long may an answer take before the assistant steps down?

The perception limits give the orientation: up to one second the flow of thought holds, at ten seconds attention breaks off. In chat it has proven useful to accept the input visibly within one second, write a notice into the thread after three seconds, give each connected system at most five seconds, and switch to the fallback path from around twenty seconds. These values are a starting point, not a law: after the first weeks in operation they are adjusted against the times actually measured.

What belongs in the announcement of a maintenance window?

Four details are enough: start and end with clock times, what is restricted during that time, which route is open instead, and when a reply will come if someone leaves an enquiry inside the window. The announcement belongs in the chat window itself, because very few visitors head for a status page. A notice the day before and a second one when the chat is opened during maintenance will do. Terms such as deployment or migration are better left out; they explain nothing and read like an excuse to the visitor.

What is logged during an incident, and for how long?

Operational data is logged: time, duration, active stage, trigger, affected system, number of conversations affected and the fallback path the visitor saw. The wording of the messages does not belong in that log; it stays in the conversation store with its own retention period. A manageable period is enough for the operational review, often 90 days; for the annual view a condensed statistic without individual cases will do. We set the exact periods together with the person responsible for data protection at your company.

When the AI assistant goes down: fallback and failover

An AI chat assistant is a component in the operation of your website, not a self-contained appliance. It depends on a knowledge base, often on an ERP system or a calendar, on a language model and on the script that loads it into the page. Every one of these connections can slow down or drop out. In the annual review by the Uptime Institute, 57 percent (Uptime Institute) of the operators surveyed said their last major outage had cost more than 100,000 US dollars, and one in five (Uptime Institute) reported costs above one million. So the real question is not whether there will be a bad day, but what your visitor reads in the chat window on that day. This article describes the stages in which an assistant steps down, the fallback path it makes visible along the way, and what ends up in the log afterwards.

Key takeaways

An outage is rarely all-or-nothing. The partial failure is far more common: the knowledge base answers, the connected ERP system does not. That is why an assistant needs stages rather than a single switch.
A timeout is a decision, not a mishap. 0.1 seconds, 1 second and 10 seconds (Nielsen Norman Group) have marked the limits of perception for decades. Wait until second 30 and the visitor is usually long gone.
The fallback path belongs in the chat window, not on a status page. 62 percent (Bitkom) of online shoppers want a person they can reach quickly when there is a problem, 52 percent (Bitkom) want an email route and 40 percent (Bitkom) a callback requested through the website.
Every incident is logged: time, duration, stage, trigger and the fallback path the visitor was shown. Without that record, any later improvement remains guesswork.

What an outage actually looks like for a chat assistant

When people say outage, they usually picture a blank page. In the daily life of a chat assistant the disturbance looks different. The knowledge base answers, but the connected stock system takes twelve seconds. The language model delivers, but the calendar returns an error. The widget loads, yet only after the visitor has already clicked on. An assistant consists of several services, and they rarely fail together. That is precisely why the binary question "is it running or not" is misleading. The useful question is: which part is missing right now, and what can the assistant still stand behind without it?

Depending on external components is not a peculiarity of this application; it is the normal state of the web. According to the HTTP Archive analysis, 90 to 92 percent (Web Almanac 2025) of the pages examined embed at least one resource from a third party, and the median page makes 79 third-party requests (Web Almanac 2025) on mobile. Each of those is a place that can slow down. For the assistant this means it is loaded onto a page that already carries a chain of dependencies, and it must not extend that chain without a plan for the case where a link is missing. How an assistant is embedded cleanly into a site and a shop is covered in our article on embedding it in a website and shop.

In brief: availability, fallback stage, maintenance window

Availability is a share of time, not a pledge. BSI Standard 200-4, in its 2023 edition, works out that 99.9 percent availability corresponds to 8.76 hours (BSI Standard 200-4) of permitted downtime per year, summed across all outages. A fallback stage is a deliberately smaller scope of service that the system still delivers when a part is missing. A maintenance window is an announced, planned interruption during which the fallback stage is active on purpose. The three terms belong together: naming an availability figure without building fallback stages merely postpones the problem to the day those 8.76 hours begin.

Timeouts: when the assistant has to stop waiting

The limits of human patience are well researched and have been stable for decades. 0.1 seconds (Nielsen Norman Group) is the threshold up to which a reaction feels instantaneous. Up to 1 second (Nielsen Norman Group) the user keeps their flow of thought, even though the delay is noticed. At 10 seconds (Nielsen Norman Group) attention breaks off and the user turns to other things. Jakob Nielsen summarised these three limits in 1993, drawing on studies that are older still. That is exactly why they hold: they describe perception, not technology. For a chat it means that an answer arriving after 25 seconds is lost even when it is factually correct.

On the technical side there are reference values a time budget can be built around. 800 milliseconds (web.dev) to the first byte counts as a good server response time. That value is far from universal: only 44 percent (Web Almanac 2025) of websites measured on mobile most recently fell into the good range. Aligning your time budget with figures like these leads to a simple rule: the page has a budget, the assistant has its own, and every connected system gets one that is smaller than the assistant’s. Only then can a sluggish query stop holding up the entire answer.

Up to 1 second: the input is visibly accepted and the assistant shows that it is working. Without that signal, any further wait feels like a defect.
Up to 3 seconds: the first answer begins. If it takes longer, a sentence appears in the conversation thread rather than just a silent loading dot.
Up to 5 seconds per external system: stock levels, calendar or order status each get their own hard limit. When it expires, the assistant answers without that detail and says so.
Up to 8 seconds: the assistant falls back to the knowledge base and drops everything it could only support with live data.
From 20 seconds: the conversation is routed to the fallback path. The visitor gets a form, a callback request or the address at which your team can be reached directly.
On every limit exceeded: a log entry with stage, duration and affected system, so the cause stays traceable later on.

The order of these limits matters. A single time value for the whole conversation means a slow stock query blocks the entire answer, even though the assistant could have answered ninety percent of the question long ago. Separate budgets per connected system turn that around: the assistant delivers what it has and states clearly what is missing. Which calls it makes in the first place, and how those calls are secured, is described in our article on controlling tools via function calling.

Stage 0: normal operation

Knowledge base, language model and connected systems answer within budget. The assistant works without restriction and without a notice to the visitor.

Stage 1: delayed answer

One source is slow. The assistant announces the delay in the thread instead of leaving the visitor staring at a loading dot.

Stage 2: no external data

Stock, calendar or order status cannot be reached. The assistant keeps answering on substance and marks the missing live data as missing.

Stage 3: knowledge base only

What remains is the reviewed content. Every answer carries a source, nothing is estimated and nothing unsupported is promised.

Stage 4: form instead of chat

The chat takes in enquiries and passes them on without answering itself. The visitor receives a confirmation with a time frame.

Stage 5: quiet withdrawal

If even the widget fails to load, the page stays fully usable. Contact route and form sit in the page independently of the assistant.

The visible fallback path instead of a silent failure

An assistant that fails silently is worse than one that honestly does less. The visitor cannot tell whether they made a typo, whether the page is stuck or whether they should wait. That is why every stage needs a sentence in the conversation thread and a route that can be clicked. The customer service figures set the order: 62 percent (Bitkom) of online shoppers prefer to turn to a person they can reach quickly when there is a problem, 52 percent (Bitkom) want an email service, 40 percent (Bitkom) a callback they can request through the website, and 28 percent (Bitkom) fall back on an FAQ. Failover mode should offer exactly these four routes, in that order.

What is missing right now, in one sentence and without jargon: "Stock levels cannot be retrieved at the moment."
What still works: "I can still help with dimensions, delivery times and accessories."
The fallback path as a button: a form, a callback request or the address that works without the chat.
A time frame for the reply: not a promise, but your team’s usual handling time.
A note that the conversation so far will be passed on, so the visitor does not have to explain everything twice.
During maintenance, the end of the window with a clock time, so the visitor can decide whether to wait or take the fallback path.

The fallback path needs the same data protection framework as the chat itself. If the assistant collects an email address or a phone number in failover mode, the same requirements apply as in normal operation: purpose, legal basis and, where needed, consent. How that is handled cleanly is shown in our article on consent for contact data in chat. Where the data sits and who processes it is answered on our page about data protection and hosting. Neither changes in failover mode, even if it feels more cumbersome on that day.

Failover mode is not a smaller chat, it is a different promise

In normal operation the assistant says: I will answer your question. In failover mode it says: I will take down your enquiry and make sure it arrives. That is a different promise, and it has to sound different too. An assistant that keeps pretending it can do everything while restricted produces exactly the answers that cause trouble later: estimated delivery times, outdated prices, invented stock levels. How to prevent that during normal operation is covered in preventing hallucinations.

Planning maintenance windows and announcing them in time

The planned outage is the only one entirely under your control. It therefore belongs in the calendar rather than in the incident category. A maintenance window for the assistant differs from one for the website: it may be shorter, it should fall into the quiet hours of your audience, and it needs its own announcement in the chat window, because very few visitors ever open a status page. What has proven itself in practice is a notice 24 hours ahead in the chat, a second one when the window is opened during maintenance, and a short reply to everyone who left an enquiry while the window was open.

Analysing your own conversations helps with the planning. When do most enquiries arrive, which topics are time-critical, which weekday is quiet? An analysis of the conversations held answers that more precisely than gut feeling, and how to read it is shown in our article on conversation analytics. It also reveals which questions would have been asked during the maintenance window. That is exactly the list from which the answers held ready in failover mode are built.

Situation	Without an operating concept	With staged fallback
External system answers late	The conversation stalls and the visitor clicks away	Answer without live data, notice in the thread
Knowledge base unreachable	The assistant answers freely and guesses	The chat takes in the enquiry without answering on substance
Planned maintenance	The widget disappears without explanation	Announced window with an end time and an open form
Visitor wants to speak to a person	The contact route sits only in the imprint	Callback and email directly in the chat window
After the incident	The number of people affected stays unknown	Log with time, duration, stage and count
Repetition	Same cause again next quarter	Trigger documented, threshold adjusted

Handover to a person: a disturbance is its own trigger

When an assistant should hand over to a person is a topic of its own, and we described the content-side triggers in handover to human agents: an explicit request, visible frustration, two unsuccessful answers, low answer confidence. The technical disturbance is added as a trigger in its own right, and it works differently. With the content-side triggers the conversation itself decides. With a disturbance a measured value decides, one the visitor knows nothing about. Both routes lead to the same person, but they need different wording and different escalation.

The most expensive outage is the one nobody noticed, because the chat window kept answering politely. An assistant that stays quiet in failover mode and shows the contact route costs less than one that guesses.

From taking over the operation of existing chat assistants

From this follows a practical rule: handover during a technical disturbance must not wait for your team to be staffed. If nobody is available, the enquiry is taken down and confirmed with a time frame. How to tell frustration signals from genuine disturbances is shown in our article on detecting frustration in chat: an annoyed visitor needs a person first, a technically disturbed conversation needs a working fallback path first. That keeping the human route open pays off is shown by the same survey the figures above come from: 86 percent (Bitkom) of respondents are satisfied with contact to a human point of contact.

Logging what actually happened

After the incident comes the part that decides how the next one goes. What was measured, how long did it take, which stage was active, how many conversations were affected, and what did the visitor see while it lasted? Together these five entries form a picture. If one is missing, the follow-up stays a story. The log should be kept separately from the conversation content: the operations entry needs time, stage and system, but not the wording of the message. This separation also makes later information requests easier to answer, because operational data and content are not mixed.

Operating an application like this is also a security topic, not purely an availability topic. Germany’s Federal Office for Information Security counts an average of 119 new vulnerabilities (BSI) per day in software products during its reporting period. A share of the incidents that begin as a disturbance end up as a security matter, and the other way round. In both cases the log is the same source. Anyone who wants to classify attack attempts on the assistant itself will find the groundwork in securing against prompt injection.

Practice outage: pull a plug once a quarter

A failover mode that has not yet seen a real incident is a claim. At a quiet time of day, deliberately switch off one connected system and watch what happens: does the right stage take effect? Is the intended sentence in the chat window? Does the button lead to a form that works without the assistant? Does an entry land in the log? This exercise takes half an hour and regularly uncovers a gap that looked tidy on paper. It also trains the part that tends to fail in practice: nearly 40 percent (Uptime Institute) of the organisations surveyed had suffered a major outage caused by human error in the three years before the survey. The matching test cases are described in our article on acceptance testing before go-live.

Getting started: an operating concept on two pages

A failover concept does not have to be a manual. Two pages are enough if they answer the right questions: which systems are attached, what time budget each one has, which stage follows which state, what sentence then appears in the chat window, and who gets notified. The effort rarely sits in the technology but in deciding what the assistant may still say while restricted. That decision belongs to the subject-matter team, not to development. A support assistant has to be treated differently from one that qualifies enquiries: in support the wrong information is the bigger risk, with an enquiry it is the lost contact.

How much technical depth is needed depends on the number of connections. An assistant that rests only on a knowledge base has two stages and is described in an afternoon. One that pulls orders, appointments and stock through interfaces needs its own line per connection. The tailwind is there: 41 percent (Bitkom) of companies with 20 or more employees already use AI, and a further 48 percent (Bitkom) are planning or discussing it. With adoption, however, expectations of operations grow too. An assistant treated as an experiment in its first year is a channel in its second, one whose absence gets noticed. Build the fallback stages only then and you build them under pressure.

List the dependencies: knowledge base, language model, ERP system, calendar, ticketing, delivery of the widget
Set a time budget per dependency that is smaller than the budget for the whole conversation
Write down stages 0 to 5 with the scope of service each stage still stands behind
Draft the sentence that appears in the chat window for each stage and have the subject-matter team approve it
Set up a fallback path that works independently of the assistant: form, callback and address
Place maintenance windows in quiet hours and announce them in the chat at least a day ahead
Define the log fields: time, duration, stage, trigger, affected conversations, fallback path shown
Run a practice outage once a quarter and feed the result back into the thresholds

Sources and studies

This article draws on data from the Uptime Institute, the BSI, Bitkom and the Web Almanac. The figures quoted refer to the state of the respective publication. It also cites the perception limits from the Nielsen Norman Group and the reference values from web.dev for server response time. An overview of what we offer around the assistant can be found under services; how an assistant handles technical enquiries in machinery is shown in our article on the assistant for technical enquiries.