A duplicate Super Chat alert is usually best investigated as a display-path problem: trace every place the event can be rendered, then remove the extra path and test the scene. Start by closing extra alert pop-outs, and then check every scene used by your continuous broadcast for repeated Alert Box widgets or Browser Sources.
If you use Streamlabs in OBS, its echo guidance includes enabling “Shutdown when not active” on relevant Browser Sources and recreating a source if the echo remains. Those are vendor troubleshooting steps, not a universal fix for every duplicate or a documented remedy for every 24/7 reconnect-related echo.
Trace every active alert path
An alert has more than one possible point of appearance. The provider supplies the alert widget or event; streaming software such as OBS renders that widget into the scene; and the scene is then part of the outgoing live picture. If two active renderers can display the same event, the viewer may see two alerts even though the underlying Super Chat happened only once.
OBS Project notes that OBS Studio does not provide alerts directly: third-party alert overlays are added through a Browser Source. That means the provider-side widget and the source or sources in OBS both matter. You can read the OBS Project explanation of how stream alerts work while checking which part of the chain you control.
Begin with the scene currently on air. Write down each alert-related source you can identify, including its name and type. Do not assume two sources are different just because their labels differ; a “Donation box” and a “Browser” source might both point to the same alert widget. Conversely, a source with “alert” in its name might be inactive or unrelated. Open its properties and confirm what it actually displays before removing anything.
Then consider every scene that the 24/7 broadcast can use. A static devotional scene may run for hours, while another scene appears for a greeting, a schedule change or a brief intermission. If both scenes contain an alert renderer and a transition briefly shows both, an alert may appear twice or in an unexpected place. A scene inventory helps distinguish a duplicate display path from a Super Chat event that was actually sent twice.
Compare what viewers saw with the channel’s YouTube event or chat record before calling it a duplicated event. Two visual alerts do not, by themselves, prove that YouTube replayed one transaction. The evidence available here supports troubleshooting the display path and provider alert echo; it does not establish a universal replay mechanism or identify the cause on your particular channel.
This distinction is useful on any always-on channel. For example, if a bhajan stream shows two identical alert animations but the channel record shows one Super Chat, investigate rendering and provider echo first. If the record itself shows two separate events, keep that evidence and investigate the event configuration rather than assuming a scene setting will solve it.
Close extra alert pop-out windows
Before changing your scene, look for a separate alert window on the streaming computer. A provider preview or alert pop-out can remain open while the same widget is also displayed in OBS. Streamlabs explicitly includes additional pop-out windows among the things to check when alerts echo. Close any extra window that is not meant to be part of the broadcast, then observe whether the remaining intended path still displays alerts.
Take care not to close the only window or application you use to manage alerts if it is needed for your setup. The point is to remove an unintended second renderer, not to disable alert delivery altogether. If you are unsure, note the window name and what it is displaying, close one extra preview at a time, and check the stream scene after each change.
A window visible only on your desktop is not necessarily visible to viewers. The relevant question is whether it is captured by OBS or otherwise contributes to the outgoing programme. If the pop-out is not captured, closing it may not change the viewer-facing output; it can still help rule out the local echo Streamlabs describes. Keep the distinction between what you hear or see on the operator’s computer and what the encoded scene contains.
Inspect scenes for repeated Alert Box or Browser Sources
In OBS, inspect the source list for the live scene and for each scene that can appear during the broadcast. Look for repeated Alert Box sources, Browser Sources connected to the same widget, or a provider’s native source used alongside its browser-widget route. Open source properties and verify the widget URL or provider identity where applicable. Avoid deleting a source solely because its name looks similar to another one.
Streamlabs documents more than one way to add its YouTube Alert Box, including Streamlabs Desktop, its OBS plugin, and a browser-source widget URL in other streaming software. These are separate integration routes, so check which route you actually use. Its YouTube alert setup instructions describe the available approaches and the use of a test function.
A practical inventory can be kept in a small table. Use the source name as it appears in your software, not a name you expect it to have. Add a note if the same source appears in more than one scene, and mark whether each scene is part of the continuous channel’s normal rotation.
| What to inspect | What to record | Why it matters |
|---|---|---|
| Current live scene | Each alert-related source and type | Establishes the visible path right now |
| Other broadcast scenes | Repeated or provider-connected sources | A scene change can introduce a second renderer |
| Alert provider route | Native widget, plugin or Browser Source | Settings and filters can differ by integration |
| Linked accounts | Which YouTube account can send events | One widget may receive events from linked accounts |
Keep one intended way to render a given alert in a scene unless you have a specific reason for having more. If you find two paths, disable or remove one at a time, then test. This controlled change is easier to reverse than clearing every alert setting at once, and it gives you a clearer indication of which path was responsible.
If your channel runs several scenes, make a note of the source arrangement before editing. That is particularly useful when another person manages a news loop or local business channel and needs to restore a scene later. The guide to rotating regional-language playlists across channels is about a different workflow, but it illustrates why tracking which scene or channel is active matters in multi-channel operation.
Check Streamlabs Browser Source settings in OBS
If your alert is a Streamlabs widget added to OBS as a Browser Source, open that source’s properties and check whether the correct widget URL is in use. Then review the Browser Source behaviour. Streamlabs’ alert echo troubleshooting guide recommends checking relevant sources across scenes and enabling “Shutdown when not active.” Treat that as a specific vendor troubleshooting step for the Browser Source path, not as a setting that diagnoses every possible echo.
The source type matters. Streamlabs says its event filters apply to browser-source widget URLs; filters do not change Alert Box sources added through Streamlabs Desktop or the Streamlabs OBS plugin. If you adjust a filter while using a native source, you may be changing a setting that does not govern that source. First confirm the integration route, then decide whether a filter is relevant.
Also confirm that the provider is configured for the YouTube account and alert event you intend to use. Streamlabs documents that linked accounts may send events through one widget URL. If more than one account is linked, check whether the shared URL is receiving events from multiple accounts; do not assume a repeated visual means the same account or event has been rendered twice.
Where account selection is unclear, review the provider’s own account and widget settings, then test with the intended channel. Streamlabs’ linked-account guidance explains the shared-widget consideration. Keep a brief record of the account selected, the source type and any filter you change. That record can prevent a later operator from undoing a deliberate choice while trying to solve a different alert problem.
For a continuously running stream, it is tempting to make several changes at once and leave the channel running overnight to see whether the issue returns. That makes the result hard to interpret. Change one relevant source setting, test the scene, and record the result before moving to another cause. The reviewed vendor instructions do not provide a guarantee for every later reconnect, so a successful immediate test should not be presented as proof of all future behaviour.
Enable “Shutdown when not active” where applicable
For each applicable Streamlabs Browser Source, enable “Shutdown when not active” in its properties. Streamlabs recommends checking every relevant Browser Source in every scene. This is a targeted check: it concerns the Browser Source route and the vendor’s described echo troubleshooting, not every native Alert Box integration, every other provider, or every cause of a duplicated visual.
After enabling it, make sure the source still loads when its scene is active. If the source is in a scene that is not currently displayed, the setting changes how that inactive source behaves; the useful test is whether the alert appears once when the intended scene is active. Do not infer that the setting has corrected a provider-side event, account selection issue or two genuine Super Chats.
If you keep a local log, note the source name and scene where you changed the property. On a 24/7 channel, a different scene may be activated by a schedule or by an operator while you are away. A small record makes it easier to check whether all relevant sources received the same treatment, without assuming that one checkbox changed every source in the project.
The broader operating problem is worth keeping separate from the alert setting. A stream can have a stable video path and still have a duplicated overlay, or it can have an alert issue while the broadcast itself is dropping. For stream interruptions, use the relevant troubleshooting path, such as diagnosing a 24/7 music stream that drops on Indian broadband, rather than treating an alert setting as a reconnect fix.
Remove and recreate a source if the echo remains
If the duplicate persists after checking the pop-outs, scene inventory and applicable Browser Source setting, Streamlabs recommends removing and recreating the Browser Source. Before doing that, save or copy the widget URL and note the source’s dimensions, position and other properties you need to restore. Then remove only the source you have identified as part of the Streamlabs Browser Source path, add it again using the intended URL, and place it in the intended scene.
Do not remove every alert-related source as a first response. A broad reset can leave the live scene without alerts and still fail to identify the original cause. Recreate one source at a time, verify its properties and test it before making another change. If you use Streamlabs Desktop or its OBS plugin rather than a Browser Source URL, confirm the applicable instructions for that integration instead of applying Browser Source steps by assumption.
If the echo remains, return to the path inventory. Check for another scene, another pop-out, a second widget URL or a linked account that can feed the same alert. If the event record shows more than one Super Chat, the visual duplication may not be the whole problem. Preserve what you observed and consult the provider’s current support guidance; the available documentation does not establish one cause for all persistent echoes.
A separate continuity issue can complicate diagnosis. If the live stream drops and reconnects, note when that occurred alongside when the alert repeated, but do not conclude that reconnect caused the echo without evidence. The troubleshooting guide for a YouTube stream interrupted when an ISP changes its public IP addresses a different broadcast problem and may help keep connection symptoms distinct from duplicate rendering.
Test the live scene after changes
Use the provider’s test function after changing the alert configuration, then watch the actual scene output. Streamlabs recommends testing its widget. A test confirms that the path you intend to keep can display an alert; it does not establish that every account, scene transition or later reconnect will behave identically. Check both the preview you operate and the output viewers receive, where available.
For a useful test, write down the scene that was active, the source that produced the test alert and whether it appeared once. If the channel uses a scene rotation, repeat the check in each scene that has its own alert source. Avoid testing several different configurations without recording which one was active, because the result will not tell you which change mattered.
When the stream is already live, avoid using a real paid Super Chat simply to test an overlay. Use the provider’s test function where it supports the alert type and configuration you need to verify. If a test alert is not representative of a live Super Chat, note that limitation rather than claiming the test proves the complete transaction path.
For an overnight channel, keep a short change log that another operator can read: what was duplicated, which scene was active, what source was changed and what the test showed. If the echo returns after a later reconnect, compare that observation with the log and the event record. The reviewed sources do not specify a 24/7 reconnect test protocol or promise that these steps prevent every reconnect-related echo.
If the recurring burden is keeping a local computer and alert scene available around the clock, StreamNeo removes the separate pain of leaving your own computer on to run a file-based 24/7 broadcast; it does not configure or troubleshoot YouTube alert paths for you. Keep alert-source checks in your streaming software or provider settings, whichever route your channel uses.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does “Shutdown when not active” stop every duplicate Super Chat alert?
No. Streamlabs recommends it for applicable Browser Sources as part of its echo troubleshooting, but an extra pop-out, repeated source, linked account or another cause may still need attention. Trace the active paths and test the scene rather than treating one setting as a universal fix.
How can I tell whether the alert repeated or the Super Chat happened twice?
Compare the visual output with the YouTube event or chat record. Two animations alone do not prove that there were two transactions, and the reviewed sources do not establish a universal replay mechanism. If the record also shows two events, investigate the event configuration as well as the scene.
Should I use a filter to stop duplicate alerts?
First confirm how the alert enters your software. Streamlabs says event filtering applies to browser-source widget URLs, not Alert Box sources added through Streamlabs Desktop or its OBS plugin. A filter on the wrong integration path may not affect the source you are seeing.
Does this fix echoes after every 24/7 stream reconnect?
No such guarantee is documented in the sources cited here. These steps address possible duplicate renderers and Streamlabs’ described alert echo checks; they do not prove or resolve every reconnect-related cause. Record when the echo happens and compare it with the active scene, source and event record.