Everything that can realistically go wrong with your button, and what to do about it. Most of the time, nothing goes wrong — paste the snippet and you're done.
Almost always one of these:
<script> tags. Look for an "embed code" or "custom HTML" block and paste the snippet there.innerHTML — scripts added that way never run. Put the snippet in your HTML template
(e.g. index.html) instead.Tip: open your browser's console (F12) — the widget logs a warning explaining what happened.
That visitor's browser can't do push notifications. Common causes:
Your site's own CSS can restyle the button (that's also what lets you theme it). Use the
builder to set colors, text, and corner radius — those settings win over page styles.
If your site has an aggressive CSS reset targeting all buttons, give the snippet's surrounding element
its own styles, or adjust via the CSS variables --twn-bg, --twn-color,
--twn-radius, --twn-bg-subscribed.
Add this service to it (replace with your notify server's address if you self-host):
script-src https://your-notify-host; connect-src https://your-notify-host
script-src is required — without it the button can't load at all.
If you can only add script-src, that's fine: the button automatically switches to a
small subscribe window hosted on the notify server instead.
That's the normal fallback, and it works fine — fans subscribe in the popup and it closes itself.
If you'd rather have fans subscribe right on your page (and have notifications come from
your domain instead of the notify server's), download sw.js
and upload it to your site's root folder, so it's reachable at yoursite.com/sw.js.
The button detects it automatically.
Note: if your site is already a PWA with its own service worker, the popup flow is used on purpose so we never interfere with your existing one.
Check these, roughly in order of likelihood:
Tip: subscribed fans can send themselves a test notification any time from the subscribe window (the popup the button opens) to check their setup end to end.
The browser remembers that choice and won't ask again — the button shows "Notifications blocked". They can undo it themselves: click the icon left of the address bar on your site → Notifications → Allow, then click the button again.
Apple only allows web push for sites that have been added to the Home Screen. A fan on iPhone/iPad needs to: open your site in Safari → Share → Add to Home Screen → open it from there → then the button works. The subscribe window shows them this hint automatically. That's an Apple platform rule; no website can work around it.
That's intentional. If you're live at the moment someone subscribes, they immediately get their first notification — so they know it works, and they can join the stream that made them want notifications in the first place. They won't get a duplicate for that same stream later.
Click the button again — it flips back to "Notify me when live". They can also revoke the notification permission in their browser's site settings, which kills the subscription on the next send (it's cleaned up automatically).
Usually within seconds — Twitch tells this service the moment you go live (EventSub). A once-a-minute check runs as a backup in case that link is ever down, so worst case it's about a minute. The notification includes your stream title, category, and a preview thumbnail, and clicking it opens your Twitch channel.
Both. Paste the same snippet on as many pages as you like — a fan's subscription covers your whole
site. And you can put several buttons with different data-channel values on one page
(for a team or community site); fans subscribe to each channel separately.
No catch. No accounts, no ads, no analytics, no tracking pixels. The only thing stored is the push subscription a fan's own browser creates — that's the technical address notifications get sent to — plus which channel they want. Nothing is ever sold or shared, and unsubscribing deletes it. The whole thing is open source, so you can check — or run your own copy.