If you want to hear when someone sends an ordinary chat message, Streamlabs documents that feature in its Chat Box widget. You can choose a sound, set its volume and decide how long chat must be quiet before a new message triggers a notification.
That sound is separate from showing chat on the stream and from automated messages about follows or subscriptions. Set up the feature that matches your goal, then check that its source stays active on the scenes where you expect to hear it.
Choose the notification you need
Start by naming what you want to happen. A private sound cue helps you notice a viewer message while you are focused on a game, playlist or other activity. A chat overlay puts messages on the video for viewers to see. An automated event message posts text in chat when a follow, subscription or another supported event occurs. These are related parts of a stream, but they are not interchangeable settings.
For an audible cue when an ordinary message arrives, use the Chat Notifications controls in Streamlabs Chat Box. Streamlabs’ setup guide for Chat Notifications describes a sound, a volume control, a cooldown and a separate threshold for how long chat must have been quiet. It is the directly relevant route for this goal; the settings do not, by themselves, mean viewers will see chat on your video.
If viewers should see messages over the picture, you need a visible chat widget or overlay and a place for it in your scene layout. OBS explains that it does not itself provide facilities to show stream chat, and that a third-party chat overlay can be embedded as a Browser Source in its stream chat FAQ. A visible overlay is a design choice: consider whether text will be readable without covering the content.
If you want a message to appear when a channel event happens, look for the appropriate event-message feature and confirm that it supports your platform. StreamElements’ Chat Alerts documentation describes configured messages for events such as follows and subscriptions. Those are event acknowledgements, not sounds for every ordinary viewer message. Decide which outcome matters before adding widgets; installing similarly named features will not make them behave alike.
A useful way to decide is to ask who should receive the signal. If only you need to notice chat, an audible cue is private to your setup. If viewers need to follow the conversation, choose an overlay. If a viewer’s action should receive a text acknowledgement, configure an event message. You can use more than one, but test each as its own feature rather than assuming that one setup covers all three.
Add the Streamlabs Chat Box widget
In Streamlabs, set up the Chat Box widget and locate its Chat Notifications feature. The precise labels and arrangement in a software interface can change, so follow the current Streamlabs instructions rather than relying on a remembered menu path. The important point is to work in the Chat Box notification settings, not in a general alerts panel intended for other events.
Choose one of the available stock sounds or upload a sound of your own, then set the volume. A restrained cue is usually easier to live with over a long session than a loud sound on every message. Listen to it at the level you actually use, including when you have headphones on or speakers nearby, rather than judging the setting from the level meter alone.
When you add the widget to streaming software, treat it as a source whose visibility and activity matter. If the Chat Box is already in your source list and you want to use it in another scene, add the existing source where the software offers that choice. Creating a fresh copy instead can leave you with duplicate sources and potentially duplicate notification sounds.
Streamlabs supports using its widget in other streaming software through a Browser Source. That is useful if your setup is not Streamlabs Desktop, but the widget still needs to be added and kept active in the application you use. OBS’s FAQ explains the Browser Source approach for third-party chat content; it does not establish that every widget or notification feature has identical behaviour in every application. Check the current widget guidance for the software you use.
Keep this step small: add the source once, give it a clear name such as “Chat Box notifications”, and verify that you are changing the intended source. If you already have a visible Chat Box for viewers, inspect it before adding another. A single widget may be serving a visible layout as well as sound, and an accidental duplicate can make troubleshooting harder.
Configure sound and volume
Select the sound that will help you notice a message without becoming distracting. A short, distinct cue is easier to identify than a long effect that competes with music, game audio or speech. If you upload a custom sound, make sure it plays correctly in the preview or test mechanism available in the current interface, and that the file is suitable for that control. The exact accepted formats and any limits should be checked in Streamlabs’ current documentation; do not assume that a sound file accepted elsewhere will work here.
Set the volume in relation to the rest of your monitoring setup. A cue that is inaudible under your programme audio will not help; one that is much louder than the content can startle you or make a long session unpleasant. Adjust it while your usual mix is playing. If you use headphones, remember that a setting comfortable through speakers may feel much sharper directly at your ears.
The notification sound is a cue for you, not an audio element that needs to be mixed into the broadcast. Check that the widget’s sound is not also being captured and sent to viewers unless that is deliberately part of your programme. Capture and audio-routing arrangements vary between applications, so verify what viewers hear with a recording or another appropriate check rather than relying on the source name.
There is a practical trade-off between reacting quickly and preserving attention. A cue for each eligible message can be useful when you are interacting with chat, but a steady conversation may make frequent sounds tiring. If your priority is to notice that chat has resumed after a quiet spell, the quiet-period threshold is more relevant than choosing a different sound. Set sound and timing together, then test the result during a real conversation or a controlled message check.
If you are also trying to keep the programme itself running unattended, treat chat notifications as a separate monitoring job. They help you notice audience activity while you are present; they do not establish that a broadcast will recover after a computer or connection problem. For that separate problem, see how an OBS YouTube stream can keep running after a power outage.
Set the quiet period between alerts
There are two timing controls to understand. Streamlabs documents a default cooldown of five seconds between sounds. The cooldown limits how often a new sound can play: as Streamlabs puts it, the next sound is allowed when a message arrives at least five seconds after the previous notification. This is a minimum spacing between sounds, not a promise that every message will make a sound.
The trigger threshold is separate. It controls how long chat must have been quiet before an incoming message triggers a sound. Streamlabs documents a range from five seconds to ten minutes. With a shorter threshold, a message can trigger a cue after a brief pause. With a longer one, the notification is more likely to mark chat resuming after an extended quiet period than to call attention to every message in a flowing conversation.
Think through an ordinary session before changing either value. In a busy gaming chat, a sound after every brief pause may still interrupt concentration. In a quiet devotional or ambience stream, a cue when a viewer returns after a longer silence may be more useful than repeated sounds in a conversation. These are different listening needs, so there is no single threshold that suits every channel.
The cooldown and threshold do different jobs even though both concern time. Raising the quiet threshold does not simply lengthen the delay after a sound; it changes how much silence must precede a message for a notification to trigger. The cooldown then prevents sounds from coming too close together. If the behaviour surprises you, change one control at a time and test again, rather than adjusting both and guessing which one made the difference.
A practical starting point is to leave the documented default cooldown in place, choose a quiet threshold that reflects how often you want to be interrupted, and listen during a test. If messages are sounding too often, consider a longer quiet period. If you miss a return to chat, try a shorter one. Streamlabs’ documented range gives room to tune this behaviour, but your own stream’s pace and audio mix should guide the choice.
Keep the source active on the right scenes
A notification can only help on the scenes where its source remains active. In the Chat Box browser-source properties, Streamlabs recommends unchecking “Shutdown source when not visible”. It also recommends adding the Chat Box source to all scenes where you want notifications to remain available. Follow the current Streamlabs documentation if the wording or location of these controls changes.
This matters during scene changes. A “Starting soon” screen, a game scene, a BRB screen and an ending scene may each have separate source lists or visibility states. If the Chat Box is absent or shut down in one of them, you may not hear the notification there. Make a scene-by-scene check: switch through the scenes you use, confirm that the source is present and not shut down when hidden, and verify that the cue remains available where you want it.
The source does not have to be visible to viewers simply because it is active for sound. Streamlabs notes that you can place the Chat Box below other sources, such as a BRB or game scene, when you want its sound but not its visible chat. In your scene order, keep it behind opaque content if the text should not appear on screen. Test the actual output, since layering and visibility depend on the rest of your scene.
If you use the same Chat Box on several scenes, add it as an existing source rather than making a separate copy for each scene. That keeps the setup easier to inspect and helps avoid duplicate sounds. The exact source-reuse wording depends on the software, so look for the option to add or select an existing source rather than creating a new widget instance.
Scene changes deserve a test because a setup that works on the main scene can fail quietly on a waiting screen. If the stream runs for long periods or rotates through a playlist of scenes, include each one in your check. For the content side of an unattended loop, the guide to streaming recorded Malayalam songs continuously on YouTube Live covers a different part of keeping a channel on air; it does not replace checking the Chat Box source in your own scenes.
Separate chat alerts from overlays and event messages
The term “chat alert” can refer to different outcomes, so use the feature descriptions rather than the name alone. Streamlabs Chat Box notifications are for a sound when an ordinary chat message meets the timing conditions. A chat overlay is visible content layered into a stream. Event-triggered chat messages are text posted in response to configured channel events. One may be useful without the others.
For a visible overlay, decide whether chat should appear in the broadcast at all. A devotional stream with a largely visual presentation may keep messages off-screen, while a discussion or gaming stream may want them visible. If you use OBS, its FAQ on stream chat describes using third-party Browser Sources rather than a built-in OBS chat display. StreamElements’ Twitch chat overlay guide is specifically about a Twitch overlay; do not treat it as evidence of an audible notification for ordinary messages or assume its platform support applies to a YouTube chat setup.
Automated messages have a different audience and trigger. StreamElements’ Chat Alerts module lets a channel configure messages for events, with available event types varying by platform. Consult its Chat Alerts documentation for the supported events and setup details. A follow or subscription acknowledgement tells chat that an event occurred; it will not tell you that an ordinary viewer typed a message unless a separate feature is configured for that purpose.
You can combine features, but give each a clear job. For example, a streamer might use a quiet sound cue for ordinary messages, keep the chat overlay hidden on the main scene, and configure an event response for a subscription. That arrangement requires separate checks: a message should test the sound, an appropriate event should test the event response, and a scene preview should test whether the overlay is visible. Do not use one successful check as proof that the other functions work.
For YouTube-specific channel activity, be careful not to infer more than the documentation says. Platform integrations and event lists can differ, and the reviewed StreamElements overlay instructions are for Twitch. If you need automated messages on YouTube, confirm the current platform support and available event types in the tool’s own documentation before building your workflow around it.
Test the notification in your setup
Test before relying on the cue during a live session. Start with the sound and volume, then send or arrange an ordinary chat message through a method that exercises the actual Chat Box notification feature. Confirm that the sound plays, then wait through your chosen quiet period and check that the next message behaves as expected. The Streamlabs guide documents the controls but does not provide a complete test procedure, so use the current interface’s available test method or a controlled message check without assuming a general alert test covers this feature.
That distinction is important. Streamlabs’ general alerts guide has a test function for alerts, but those alerts are not the same as Chat Box sound notifications for ordinary messages. A successful test of a follow or subscription alert does not prove the ordinary-message sound works. Likewise, seeing a message in a chat overlay only proves that the visual source displayed it; it does not establish that sound, cooldown and quiet threshold are working.
Check the scenes individually. Test the main scene, any starting or intermission screen, and the scenes you use when stepping away. Confirm the source is available even when it is behind another source or not visible. If the cue disappears only after a transition, revisit the source’s scene coverage and the “Shutdown source when not visible” setting rather than replacing the sound file first.
Listen for unintended broadcast audio as well. If the sound is meant only for you, confirm that it is not appearing in the programme mix. You can check a local recording or use another suitable monitoring method. The result depends on how your streaming application captures browser-source audio, so do not assume that a private cue stays private without checking.
Write down the settings that worked for your use: sound choice, volume, cooldown, quiet threshold, and scenes containing the source. That short note makes the setup easier to restore after you change scenes or rebuild a profile. If you use several widgets, label them by purpose, such as “ordinary chat sound” and “visible chat overlay”, so a later adjustment does not affect the wrong feature.
If chat activity is only one part of a larger live setup, keep the operating plan equally specific. A notification does not keep a source file looping or prevent a stream from stopping at the end of an input. For that case, see why an FFmpeg YouTube stream can go offline at the end of an input file. When the file and channel are ready, StreamNeo can remove the need to keep your own computer on for a file-based 24/7 YouTube broadcast; it does not change how Chat Box notifications behave.
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
How do I get notified when someone chats?
Set up Streamlabs Chat Box and configure its Chat Notifications sound and volume. Then choose the quiet-chat trigger threshold and confirm the source is active in the scenes where you want to hear it. A visible chat overlay or an event message is a separate feature.
Will the sound play for every message?
Not necessarily. The cooldown spaces sounds apart, while the separate trigger threshold determines how long chat must be quiet before a message can trigger a sound. With a longer quiet period, the cue is more about chat resuming than every message in an active conversation.
Does a chat notification show messages to viewers?
No. The sound notification is distinct from a visible chat overlay. If viewers should see messages, add and configure a suitable overlay separately, then check its visibility in each scene.
Do follows and subscriptions trigger this sound?
The Chat Box ordinary-message notification is not the same as an automated response to a follow or subscription. Configure an event-message feature separately if you need acknowledgements, and check its current documentation for platform support and available events.