If you want to change the sound for a new follower, subscription or donation alert, edit that event in your alert provider’s settings. OBS Studio may display the alert as a browser source, but it does not control which sound the provider assigns to that event.
The practical sequence is to identify the event, choose a replacement sound in the provider, save the change and test it through the setup you use to stream. That keeps a follower sound change from accidentally becoming a broader change to unrelated alerts.
Identify the event you want to change
First decide which alert should sound different. Providers commonly keep settings for different event types separately: a new follower, a subscription and a donation can each have their own sound. A change to one event should not be assumed to change the others.
If you are unsure which event is firing, use the provider’s preview or test control before editing. Check the on-screen message as well as the sound. For instance, if the alert says “new subscriber” but plays the old follower sound, you have a more useful clue than simply hearing a sound you dislike.
The platform matters too. A provider may have separate event groups or settings for different connected platforms. Choose the channel or platform you intend to use, then choose the event within it. Do not change a similarly named event under another platform and assume the change will carry over.
Write down the event you are changing before you start, particularly if several alerts have similar names. A short note such as “YouTube: new member” can save you from changing the wrong sound when you return to the settings later.
Open the provider’s Alert Box settings
Open the dashboard or application for the service that supplies your alerts. With Streamlabs, sound assignments are in Alert Box settings. The Streamlabs guide describes selecting the platform and alert type, then changing that event’s sound. Its current documented sound routes include the sound library, an uploaded audio file or an audio URL; check the current controls in your account because interfaces can change. See Streamlabs’ instructions for changing Alert Box sounds.
The place that displays an alert and the place that configures it are not always the same. In a browser-source setup, your streaming software loads a widget supplied by an alert provider. The provider’s settings determine the widget’s alert appearance and sound; the streaming application presents that widget in the scene. OBS’s alert setup guide describes using alert providers with OBS and points to the provider for customising alert images and sounds.
For Streamlabs, you may also manage an Alert Box source in Streamlabs Desktop. Its documented workflow lets you choose an alert type and change its sound in that application. If you use another provider, such as StreamElements, open its AlertBox in the Overlay Editor and confirm the controls currently shown in your account. StreamElements’ Alert Box gallery shows that the widget is customisable, but do not assume its menu labels match Streamlabs’.
If you have already added a provider widget to OBS, there is usually no need to rebuild the scene just to change its sound. Go to the provider’s sound assignment first. Later, you can check whether the widget needs refreshing to reflect the saved change.
Choose or upload a sound for that event
In the selected event’s settings, find the sound control. In Streamlabs, the documented options are an item from its sounds library, an audio file you upload, or an audio URL. The exact control and catalogue may change, so use what the current dashboard offers rather than relying on an old screenshot.
A stock library is convenient when you want to choose and test a sound without finding a file yourself. Search or browse for a sound that suits the event: for example, a short bell for a new follower may be easier to distinguish from a longer membership alert. Do not presume that every catalogue item is free or available to every account. Check the current library labels and terms before building your setup around a particular sound.
An upload gives you more control over the sound and its identity, but you need to select and manage the audio file yourself. Use a sound you have permission to use in your stream, including if the stream is monetised. A file being easy to download does not establish that you have permission to broadcast it.
Before uploading, check the provider’s current requirements for file type and size in its interface or official help. The available research does not establish a universal format or upload limit, so it would be misleading to tell you that one particular file specification always works. Keep your original file somewhere you can find it if you later need to replace the upload.
The choice is a trade-off between convenience and control. A library selection avoids managing a separate file; an upload lets you choose a sound that fits your channel more closely. In either case, listen to the preview if available and consider how it sits alongside speech or music. An alert that is distinctive in a quiet preview may be hard to hear over a busy devotional or local-news loop.
Consider the dashboard audio URL option
If the provider offers an audio URL control, it can use audio hosted at a web address rather than a file selected from a library or uploaded directly. Streamlabs’ current sound guide includes this route. It can be useful when you already have a sound available online, but it adds a dependency: the address must remain reachable and point to the intended audio.
Before using an external URL, check that you control the file or have permission to use it, and that the host allows the way you intend to use it. A URL that works in your browser today may later change, expire or become inaccessible. If the alert goes silent after a change to your hosting or link, that is one of the first things to check.
Compare the three routes by what you need to manage:
| Route | What it is useful for | What to check |
|---|---|---|
| Provider library | Choosing from sounds already presented in the dashboard | Current availability, account terms and whether the sound suits the event |
| Upload | Using a chosen file without depending on an outside address | File requirements, rights to use it and keeping the source file available |
| Audio URL | Pointing the provider at audio hosted elsewhere | Rights, access, and whether the address will remain valid |
An uploaded file avoids relying on an external address remaining available, though you still depend on the provider’s handling of the upload. A URL can be convenient, but you are responsible for the external link continuing to work. Pick the simplest route that fits your source and your rights to use the sound.
Save the change before leaving settings
Selecting a sound is not the same as saving it. Use the dashboard’s save control after making the change, and wait for any confirmation the interface displays before navigating away. Streamlabs’ quick guide to setting up alerts specifically reminds users to save settings before moving to other menu items.
If you are changing several events, save the first one before moving to the next. Then return to that event or reopen its settings and check that the selected sound remains. This gives you a simple way to catch an unsaved change while you are still in the dashboard, rather than discovering it during a live broadcast.
If the provider has a separate save button for each event, treat each event as its own change. Do not assume that saving one alert also saves the next event you have edited. Likewise, if the interface has a general save control, use it after all the changes and check for confirmation.
Avoid changing the sound, closing the tab immediately and assuming it will persist. A quick review of the event and its selected sound is worthwhile, especially when you are preparing a channel that needs to run unattended. The guide to keeping a YouTube channel live with pre-recorded videos covers the wider continuity task; alert configuration is one small setting to verify before you leave a channel running.
Add or refresh the alert in your streaming setup
After saving the provider setting, check how the alert reaches your stream. In OBS, a common arrangement is to add the provider’s alert widget URL as a Browser Source. OBS displays that widget; the provider remains responsible for the event’s sound assignment. If you have not yet set up that connection, follow the provider’s current instructions to obtain its widget URL and add it as the appropriate source.
A change saved in the provider may appear without rebuilding the source, but a loaded browser widget can sometimes need a refresh to show updated settings. Preview the alert from the provider or use its test event, then confirm what you see and hear in your streaming setup. If you need to refresh the source, do it before going live and test again afterwards.
If you use Streamlabs Desktop, its documented route is to add an Alert Box source if needed, select the event, change the sound and choose Done to save. The precise controls can change, so use the current application interface. If you use StreamElements, make the sound change in its AlertBox editor and check its own current instructions rather than borrowing Streamlabs menu steps.
For a channel that plays a pre-recorded video continuously, alerts are a separate layer from the video loop. Check that the alert can be heard over the programme audio without overwhelming it. If your wider production uses separate music and alert sources, the guide to remotely mixing audio for a live stream can help you think through how those sources fit together. For a more technical broadcast workflow, adding a YouTube stream key to FFmpeg on Ubuntu is a different task from assigning an alert sound, but both need to be checked in the actual output path.
Test the event and troubleshoot the result
Test before going live. Verify that the intended event appears, the new sound plays, and the sound reaches the output you expect. If the provider offers a test button, use it; then monitor the streaming application as well, since a sound heard in a dashboard preview does not by itself confirm how it will reach your live stream.
If the alert appears but is silent, start with the event assignment. Confirm you changed the right platform and alert type, that the sound is still selected, and that you saved the settings. Next, check the widget or alert source and the audio routing used by your streaming application. If you use multitrack recording, Streamlabs’ alert troubleshooting guidance calls out checking audio-track selection; the relevant audio output can depend on your particular setup.
If the alert appears but the old sound remains, refresh the widget or source after confirming the provider saved the replacement. Then run the test again. Avoid making several unrelated changes at once: one change followed by one test makes it easier to identify what fixed the problem.
If the alert sound plays twice, check whether two alert sources are active or whether both the provider application and OBS are sending the same audio. Duplicate routing is one possible cause, not a universal explanation. Mute or disable only the suspected duplicate source temporarily, run another test and restore the intended setup once you have identified the path.
When the result is correct, make a note of the event, chosen sound and any source routing you changed. That is useful if another person maintains the channel or if you return later to update a sound. The same habit helps when you run a channel for long periods: a short check before broadcasting is more dependable than assuming a setting survived because it looked right in the dashboard.
Keep the change narrow and documented
Changing one alert at a time is not needless caution. It helps preserve a distinction between events: a short follower cue can remain recognisable while a membership or donation alert keeps its own sound. If every event is assigned the same file, the alerts may still work, but you lose that audible distinction and may find it harder to know what happened while you are not watching the screen.
Keep a simple record if you manage several alert types. A note with the platform, event, sound source and date you last tested it is enough; it need not become a complicated checklist. If a sound comes from a URL, include the location you used and who controls it, without storing account secrets in a shared note.
For a scheduled or unattended stream, remember that changing the provider’s alert does not replace testing the full broadcast path. You still need to confirm the widget is present in the right scene and that its audio is included in the stream mix. StreamNeo removes the need to keep your own computer switched on to run an uploaded video as a 24/7 YouTube stream, which helps when local machine availability is the specific problem; it does not change the need to configure and test your alert provider separately.
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 control the sound assigned to my alert?
No. When OBS displays an alert provider’s widget as a browser source, the provider’s settings control which sound is assigned to the event. OBS may still affect whether the widget and its audio reach the stream, so test the complete setup after saving the provider change.
Will changing a follower alert also change subscriptions or donations?
Not necessarily. Alert types are configured individually in Streamlabs, and other providers may organise their events differently. Select and check each event you intend to change rather than assuming one selection applies everywhere.
Why does the alert show on screen but make no sound?
Check that the sound is assigned to the correct event and that the provider saved the change. Then check whether the alert source’s audio is routed to the output or track that reaches your stream, and test again.
Can I use any sound file or URL?
Use a file or URL only when you have permission to use that audio in your stream, and check the provider’s current upload requirements or URL controls. An external address can stop working or become inaccessible, so test it through the alert before relying on it.