When a stream alert is missing, first check whether the alert provider generated it; then check whether your streaming software displayed and played the overlay. Those are separate failure points, so a successful provider test does not guarantee that real events will work, and a visible Browser Source does not prove that its audio is reaching your stream.
This guide follows that split for OBS Studio, Streamlabs Desktop and other software that can host a third-party alert widget. Work through the checks in order, changing one thing at a time so you can tell whether the problem is provider-side, visual, or audio-related.
How third-party alerts reach OBS
OBS Studio does not directly provide stream alerts. An alert provider generates events and supplies an overlay; OBS displays that overlay through a Browser Source. Streamlabs Desktop has its own Alert Box source, while other streaming applications may use a provider’s widget URL in a browser source. The exact setup path depends on the provider and application, so follow the relevant current setup instructions rather than assuming every alert service works identically.
This distinction helps locate the failure. If a provider dashboard test does nothing, first investigate the provider’s event settings, account connection or widget. If its test appears in the provider preview but not in OBS, focus on the source, scene and display state. If the alert appears but is silent, investigate audio routing separately.
A useful starting point is the OBS Project’s guide to adding stream alerts. It explains that alerts come from third parties and are brought into OBS as a Browser Source. For the broadcast itself, a different set of checks applies: our guide to telling a stream-health warning from a playback problem is useful when the live picture, rather than the alert overlay, is in question.
Before troubleshooting, note which alert provider you use, which software hosts the overlay, and which scene you are testing. A source added to a starting scene may not exist in the scene currently on air. Similarly, configuring an alert in a provider dashboard is not the same as adding its widget to OBS. Keeping those roles distinct prevents you from changing the wrong settings.
Test whether the provider generated the event
Start in the provider’s dashboard, not with a real donation, subscription or other audience event. Save any alert settings first, then use the provider’s test function for the event type you are troubleshooting. Observe the provider preview, and, where available, note whether the test reports that the event was sent. The test is a controlled check of that provider path; it does not establish that every real event, account or platform connection will behave the same way.
If the test does not appear even in the provider’s preview, check the event type and its enabled state. Confirm that the provider is connected to the intended account and platform, and that you have saved changes before leaving the settings page. If a connection looks stale, review the provider’s instructions for linking or reconnecting the account rather than repeatedly changing OBS sources.
Next, consider filters and moderation. An event may be held for review, or an alert may be suppressed by profanity or custom-word rules. Streamlabs notes that an unlimited moderation delay can require manual acceptance before an alert plays. It also documents that some subscribers’ privacy settings can prevent an alert from appearing because of API limitations. Those are provider- or platform-side conditions; rebuilding a Browser Source will not make a filtered or unavailable event appear.
If provider tests work but actual events do not, compare the real event with the test: was it the same event type, platform and account? Check any event-specific enablement, moderation queue, filters and account connection. For a Streamlabs-specific sequence, see its alerts and widget troubleshooting guide and quick guide to setting up alerts. Their instructions apply to Streamlabs; another provider may use different names or controls.
Check the Browser Source and overlay
Once the provider can produce a test, check how the widget is added to your streaming software. In Streamlabs Desktop, the setup uses its Alert Box source; the Streamlabs OBS plugin and other software can have different source paths. For another application, the provider may instruct you to paste a widget URL into a Browser Source. Use the source type and instructions for your particular combination rather than copying a setup from a different application.
In OBS, select the scene you are testing and confirm that the intended Browser Source exists, is enabled, and is not hidden. Look at the source order: a camera frame, image or other opaque source layered above the widget can cover it. Temporarily move the alert source higher in the list or hide likely obstructions, then test again. Restore the intended layout once you have isolated the cause.
Check the source’s properties and dimensions as well. A widget can be present but positioned outside the canvas or constrained to an area where the alert is not visible. If it seems stale or stops responding, refresh the source if that option is available. If the problem persists, remove and recreate the widget source using the provider’s current URL and setup steps. Do not post a private widget URL publicly; anyone with access may be able to use it.
Browser hardware acceleration is a later visual check. Streamlabs recommends trying the relevant hardware-acceleration setting in the streaming software’s advanced settings and restarting the application. Treat this as a diagnostic change: note the original setting, change it, restart, and test. If it makes no difference, restore the prior setting. A change here can affect browser rendering generally, so it is not a universal alert fix.
Custom HTML or CSS can also alter an overlay’s appearance. If you use custom code, temporarily test the provider’s standard layout or review your edits for hidden, transparent or misplaced elements. Avoid replacing several parts at once: if the stock layout appears and your custom one does not, you have narrowed the cause to the overlay design rather than the event generator. A guide to using a YouTube stream key for a continuous OBS stream covers a separate broadcast setup issue; it cannot substitute for checking the alert widget itself.
Check alert visibility and playback
Test in the actual scene where the alert should appear. A source can be configured correctly in one scene and absent, hidden or covered in another. If you use multiple scenes, inspect each one in which you expect alerts. Where you have duplicated sources, check whether you are editing the source instance or shared source you intend to use.
For Browser Sources, check whether the source is meant to shut down when it is not active. OBS offers a “Shutdown when not active” setting in Browser Source properties. If it is enabled, the source may stop while its scene is inactive and start again when you return; that behaviour can be useful, but test the transition in your scene workflow. If it is disabled, an overlay may continue running in another scene. That can contribute to repeated alerts or echoes when multiple copies are active. Streamlabs’ guide to fixing alert echoing describes checking extra pop-out windows and inactive-scene sources.
Distinguish the provider preview from the programme output. Confirm the alert is visible on the OBS canvas, then check the stream output or a short local recording if practical. A preview may show a source that is not included in the scene currently being broadcast. Conversely, a transition between scenes may interrupt an alert even if it works when tested in a static scene. This check tells you whether the overlay is merely present in the editor or is actually part of the composition you intend to send.
If the provider test is visible in the scene but does not reach the output, revisit scene selection, source visibility, source order and any transitions. If it reaches the output twice, look for duplicate Browser Sources, multiple alert windows or overlapping scenes. Correct only the source or scene you have identified; disabling every alert source may hide the symptom without finding why it repeated.
Troubleshoot missing sound
An alert can render visually while its sound is muted, routed to the wrong place or excluded from the stream mix. First inspect the provider’s recent events or alert settings for a mute state and confirm that the test alert has a sound assigned. If it uses a custom audio file, verify that it is still available to the provider and that the selected event type is using it.
Then inspect OBS audio controls. Check whether the alert source appears in the audio mixer and whether its meter moves during a provider test. A moving meter suggests audio is reaching OBS, but not necessarily the stream’s intended mix. Review the source’s audio routing, the monitoring device selected in OBS advanced audio settings, and which output tracks are enabled for the broadcast or recording. The right monitoring choice depends on whether you want to hear the alert locally and which device you use; test rather than assuming the default is correct.
Some provider setups have a “Route Audio to OBS” option on the alert source. Enable it only where the provider’s instructions call for it, then test again. If you change monitoring or track assignment, make a short recording or listen to the stream mix so you know whether the audience would hear the alert. Headphones connected to your computer are not proof that the audio is present in the encoded output.
Use a provider test alert to compare the sound at each point: provider preview, OBS mixer and a recording or stream mix. If the provider preview is silent, revisit the alert’s sound assignment or mute setting. If OBS shows no audio activity, check the source and provider-specific routing. If the meter moves but the recording is silent, inspect the selected audio track and output routing. This sequence narrows the fault without treating “no sound” as a single setting.
Retest after each change
Make one change, then repeat the same test. If you change source order, test before changing hardware acceleration. If you alter audio routing, keep the visual setup unchanged. This makes the result interpretable: you can revert a change that has no effect, and you avoid ending with several new settings whose contribution is unclear.
Keep a brief note of the scene, event type, test result and setting changed. For example: “Provider preview shows test; OBS scene ‘Main’ does not; moving Browser Source above the frame makes it visible.” That record is especially useful if you later need to compare a test alert with a real event or ask the provider for support. Do not include private widget URLs, account details or stream keys in a public post.
After the basic checks, move to less common causes. Streamlabs lists cache clearing, firewall or antivirus permissions, IPv6 issues and incorrect system date or time among other troubleshooting checks. Those are not first steps: the source, provider settings and audio route should be isolated first. Follow the provider’s current instructions before changing network or security settings, because the exact steps depend on your system and service.
If you broadcast continuously, keep alert checks separate from stream-uptime checks. A healthy YouTube broadcast can carry a broken overlay, and an alert test can work while the broadcast itself is offline. For a longer-running channel, consider documenting who checks provider events, which scene is the main one, and how to confirm audio after a restart. Our article on testing a YouTube streaming service before moving an always-on channel offers a broader migration checklist, but alert providers still need their own test.
Prepare a pre-stream alert check
Before going live, use a short repeatable checklist. Confirm the intended provider account and event types, save provider settings, and run the provider’s test. Then check that the alert source is enabled in the scene you plan to use, visible above obstructing layers, and placed within the canvas. Finally, confirm the test sound in the output mix, not only on your headphones.
If you use several scenes, test the transitions that matter to your show. A devotional channel switching between a holding screen and a live host scene, for example, should verify that alerts are present where they are meant to be and absent where they would obscure text. A local news loop may prefer alerts only in a dedicated scene. The relevant check is not whether every scene contains a widget, but whether the intended one behaves as designed.
For a 24/7 channel, consider whether external audience events should interrupt the programme at all. If alerts are part of the format, decide which events are enabled and how moderation works before leaving the channel unattended. If the channel mainly plays a continuous video, a quiet overlay policy may be more appropriate. The operating choice is editorial as well as technical; do not enable event types simply because they are available.
StreamNeo can remove the need to keep your own computer running for a continuous uploaded-video broadcast, but that does not replace checking the alert provider, its event settings or the scene’s overlay. Keep this pre-stream alert test as its own routine, even when the underlying channel is intended to run continuously.
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 OBS Studio provide alerts?
No. OBS Studio hosts overlays from third-party alert providers, commonly through a Browser Source. You need to configure the event with the provider and add its overlay to the scene in your streaming software.
If the provider test works, are real alerts fixed?
No. A test shows that the provider’s test path can generate an alert; real events may still depend on event type, account linking, moderation, filters or platform privacy settings. Check the specific real event configuration if tests work but audience events do not.
Why can I see an alert but not hear it?
The alert sound may be muted, missing from the selected event, routed to a different device or excluded from the output track. Check the provider settings, OBS mixer and audio routing, then verify with a recording or stream mix.
Why does the same alert play more than once?
Look for extra alert pop-out windows or duplicate Browser Sources running in different scenes. Check the Browser Source’s inactive-scene behaviour, and test after closing or disabling only the duplicate you identify.