Nothing appears in the corner, and nothing says why

The tag is on the page, the page loads normally, and there is no launcher in the corner.

In rough order of how often each one turns out to be the answer. Work down rather than across: each carries a way to tell whether it is yours before you change anything.

• 1

  The tag is not actually on the rendered page

  Why

  Templates, caching layers and optimisation plugins all swallow markup for their own reasons, and the tag being in your editor is not the same as the tag being in the document the browser received.

  How to confirm it is this one

  View source on the live page, not the developer tools inspector, and search for w.js. The inspector shows the DOM after scripts have run; view source shows what was actually delivered.

  Fix

  If it is missing from the source, the problem is upstream of the widget: a cache that has not been purged, a template that is not the one rendering this page, or an optimisation plugin excluding third-party scripts. Fix the delivery, then reload.

• 2

  data-key is missing or empty

  Why

  The loader reads the key off the tag it was loaded from and stops immediately if there is not one, because without a key it has nothing to fetch a configuration for.

  How to confirm it is this one

  The browser console contains a warning from chat-widget saying the data-key attribute is missing from the script tag. It is the only case that names itself outright.

  Fix

  Copy the tag again from the install tab of the assistant rather than retyping it. The usual cause is a template engine escaping or stripping the attribute, so check the page source for the attribute rather than the file you edited.

• 3

  The assistant is paused

  Why

  The configuration carries a status, and the loader returns without rendering anything unless it is active. A paused assistant is a deliberate off switch and it looks exactly like a broken install.

  How to confirm it is this one

  In the network tab, find the request to the widget configuration endpoint. It returns 200 with a status field. If that field is not active, this is your answer.

  Fix

  Set the assistant back to active in the dashboard. Note that the configuration is cached for a minute, so allow that long before deciding it did not work.

• 4

  The origin is not on the allowlist

  Why

  The configuration request returns normally but carries a flag saying this origin is not permitted, and the loader renders nothing rather than showing a widget that would refuse to talk.

  How to confirm it is this one

  The console carries a warning from chat-widget saying this origin is not on the allowlist. In the network tab the configuration response has an origin_allowed field set to false.

  Fix

  Add the exact origin to the allowed sites for that assistant. There is a page on this in more detail, because the exact rules catch people out.

• 5

  The configuration request never completed

  Why

  A network failure is caught and swallowed, on purpose: a widget that throws on a customer's site during an outage is worse than a widget that is absent.

  How to confirm it is this one

  The network tab shows the configuration request failing, blocked, or never issued at all. Blocked usually means a content policy or an extension; never issued usually means the script itself did not load.

  Fix

  If the script did not load, check whether an ad blocker or a network filter is removing it, and try in a private window with extensions disabled. If it was blocked by policy, see the content security policy page.

• 6

  Something is already installed under the same name

  Why

  The loader checks for its own global before doing anything and returns if one is already there, so a second copy of the tag on one page silently does nothing.

  How to confirm it is this one

  Search the page source for w.js and count the matches. Two is the answer. This is common when a tag sits in both a theme footer and a tag manager.

  Fix

  Remove one of them. Which one to keep depends on which is easier to maintain, but leaving both is not harmful, only confusing when you come to change the key.

If the configuration request returns 200, origin_allowed is true, the status is active and there is still nothing in the corner, look at whether anything is rendering the widget off screen. The launcher is positioned from the bottom and the side by the offsets in the appearance settings, and an offset large enough to push it outside the viewport is a real, if unusual, cause.

Why does it not just show an error on the page?

Because the page belongs to you and your visitors, not to us. A widget that renders an error banner on a live site during a configuration mistake would be doing more damage than the mistake. Everything it wants to say goes to the console instead.

Do I need to wait after changing something?

Up to a minute. The configuration is cached for that long, both on our side and by the browser, which means a change to the appearance, the status or the allowed sites is not always instant.

It works on my laptop and not for a colleague. What is different?

Almost always an extension, a corporate network filter, or a different origin. Ask them for the console output and the origin in their address bar and compare it against the allowlist character for character.