Failure visibility
When an assistant does not answer, the worst outcome is not the missed answer. It is nobody being able to say why. Was the information missing? Was the AI provider slow? Did something fail after the answer was written?
ChatHQ records the reason for every turn that ends without an answer, and keeps two very different situations apart.
Knowledge gap or service disruption
- Knowledge gap — The assistant ran normally and chose not to answer: no matching documents, or not enough confidence that the answer was supported. This is the assistant doing its job, and the visitor sees your fallback message. See Evidence verifier.
- Service disruption — Something failed: the AI provider timed out or returned an error, the request was rate limited, or an answer was produced but lost on its way out. The visitor sees a short, neutral service notice, never your fallback message.
This distinction protects your fallback wording. A visitor is never told "I don't have that information" when the truth is that a provider was briefly unavailable. The two cases are also counted separately, so a bad hour at a provider does not look like a gap in your content.
What is recorded
For each turn that falls back, ChatHQ stores the reason and the stage at which it happened:
- Before generation — Rate limited, blocked by a safety check, invalid request, engine unreachable.
- During generation — Model timeout, provider error, content filter, question and context too long for the model.
- After generation — The answer existed but was lost while being formatted, cited, stored or streamed.
- By choice — No matching documents or low confidence. This is the knowledge-gap group above.
Every record carries a trace id, so a single reported problem can be followed from the conversation into the logs.
What you can do
- Watch the fallback rate — A rising share of fallbacks on an assistant usually means the content has gaps. Read the questions that fell back and add the missing material. See Analytics dashboard.
- Report disruptions with the time — If visitors report the service notice, send support the assistant and the approximate time. The recorded reason tells the team exactly what happened.
- Check the API flags — API responses carry
fallback_triggered, so your own monitoring can count fallbacks on your side. See the REST API.
Related
Was this article helpful?