Troubleshooting

The widget does not appear

Open the browser console on the page.

• missing agent id — the tag has no agent. Add ?agent=your-agent to the script URL, or a data-agent attribute.
• Nothing at all in the console — the script never loaded. Check the tag is actually in the delivered HTML (view source, not the inspector), and that no consent tool is holding it back until the visitor accepts.
• Blocked by Content-Security-Policy — allow the widget’s host in script-src and connect-src.

If the launcher is on the page but underneath something else, move it with offset-bottom and offset-side rather than fighting it with CSS — see embedding the widget.

It loads but says the assistant is unavailable

The agent is paused. Resume it in Workspace → Agents.

Every answer is “I don’t know”

In order of likelihood:

1. The index is empty. Workspace → Knowledge → Website crawler — if the page count is zero, the sitemap URL is wrong, unreachable, or being refused by your own bot protection. Press Check access there; it answers all three in one go (bot protection).
2. The pages indexed have no text. A chunk count of zero on pages that clearly have content means the content is rendered by JavaScript after the HTML arrives. The crawler reads what your server sends. Server-render it, or add the facts as snippets.
3. Strictness is too high for a site that answers things obliquely. See answer quality.

Answers are confident and wrong

Open the conversation and look at the retrieval score on the bad message.

• Low score — it wrote well from bad evidence. Lower the strictness setting’s tolerance, or fix the content. Do not add an instruction telling it to be accurate; that does not work.
• High score — it retrieved the right page and misread it. Usually the page itself is ambiguous, or two pages contradict each other and it picked one. Search the index for the fact and see what it found.

Answers are long, hedged and unhelpful

Almost always too much retrieval, not too little. Lower Top-K. A model given twelve loosely-relevant passages writes something that covers all of them.

A page I published is not being answered from

1. Is it in the sitemap? Nothing outside the sitemap is crawled.
2. Does it match an exclusion pattern?
3. Has the crawler run since you published? Press Crawl now rather than waiting for 03:10 UTC.
4. Is it in the page list with status ok and a non-zero chunk count?

If all four are yes and it still is not surfacing, the page probably uses your internal vocabulary and visitors use theirs. That is a content gap, not a crawler problem.

The microphone does not work

The permission belongs to the site the visitor is on, not to Engadin. If they denied it once, the browser remembers and will not ask again. Point them at https://engadin.ai/help/microphone, which the widget already links to when this happens.

Inside an iframe, the embedding page must grant it: allow="microphone". Without that attribute the browser refuses regardless of the visitor’s own settings.

Chat requests are being refused

Check the security digest, or Overview → Analytics, for the rejection type. Abuse limits lists what each one means.

origin_block on your own site means the agent’s website setting does not match where the widget is embedded, or the hostname it is embedded on has not been added under Your domains. budget means the platform-wide daily cap is spent and chat has stopped for everyone.

Nothing has been crawled for days

The daily seed runs at 03:10 UTC and the queue drains every two minutes. If the queue has depth but the page count is not moving, your server is probably refusing the crawler. The page list shows the error against each affected URL: timeouts, 403s from a firewall, and rate limiting all appear there by name.

The usual culprit is bot protection answering with a challenge instead of the page — a managed challenge on Cloudflare, a WAF rule, a security plugin. Press Check access on the crawler page: it asks your site live, names what is refusing us, and gives you the rule to write. See bot protection.

When you need to look deeper

Anomaly notifications fire on their own when turns start failing or retrieval comes back empty. If you are debugging something intermittent, turn that topic on first — it will tell you when it happens, which is better than trying to reproduce it.

An old embed on a customer site broke

It should not have. Hostnames the platform has used before keep serving every endpoint, permanently; only browser pages redirect. If a tag on an old host has genuinely stopped working, that is a bug worth reporting rather than something to fix by editing the customer’s site.