A Wowza stream does not have one universal restart switch for every disconnect. First establish whether Wowza stopped receiving its source or whether its outgoing YouTube target failed; the status and recovery steps differ.
If the source returns, a configured target may resume, but do not rely on that behaviour without checking the target and YouTube preview. When the source is active and the target is in Error, diagnose the destination path before considering a limited, monitored retry.
Find where the stream path failed
Think of the broadcast as two linked connections: your encoder or other publisher sends an incoming stream to Wowza, and Wowza sends that stream onwards to YouTube through a Stream Target. A disconnect can happen on either connection. Restarting the wrong side may do nothing, and restarting the whole Wowza service can interrupt streams that were otherwise healthy.
Start by noting the time the failure began and the names of the application, incoming stream and target involved. Then check the incoming stream and target separately in Engine Manager. Do not infer the failed component from the YouTube player alone: a blank preview could result from a source outage, a target connection failure, or a YouTube event that is not receiving the expected feed.
| What you observe | What it suggests | First action |
|---|---|---|
| Incoming stream is absent or not Active | The publisher-to-Wowza leg may have stopped | Check the encoder, publisher and expected stream name |
| Input is Active; target is Waiting | The target may be awaiting its source or completing connection initialisation | Confirm the input, then allow time for initialisation and recheck |
| Input is Active; target is Error | Wowza could not connect to the destination | Check target details, logs and the YouTube event before a controlled retry |
| Target is Active; YouTube preview is absent | Wowza reports pushing, but end-to-end receipt is not confirmed | Check Live Control Room and the event's ingest feedback |
These are diagnostic clues, not proof of a single root cause. For example, an Active incoming stream shows that Wowza sees its input; it does not prove that the YouTube key, destination or event is correct. Keep a short incident note as you work, so that the next operator can tell whether a retry changed anything.
If the incoming feed is reaching Wowza but its picture looks soft, that is a different problem from a dropped target. The checks in this guide to why a 24/7 YouTube stream can be stuck at low resolution may help once the connection is stable; changing resolution will not repair a failed destination connection.
Check the input source first
In Engine Manager, open the Incoming Streams view for the application and find the exact stream name configured as the target's source. Confirm whether it is present and Active, and inspect its connections, uptime and throughput. Wowza's guide to streaming to YouTube from Streaming Engine recommends checking the incoming stream and its detail before troubleshooting the outgoing destination.
If the stream is missing or stopped, look upstream. Confirm the encoder or publisher is running, is publishing to the intended application, and is using the expected stream name. If it runs on a computer at the venue, check that the machine has not slept, lost network access or closed the broadcasting application. If it is a camera or another encoder, check its own connection and publishing status. Resolve the source problem first; a target cannot send video that Wowza is not receiving.
When you restore the publisher, watch the input status rather than assuming that pressing Start has restored the feed. Verify that it becomes Active and that data is arriving. Then inspect the target again. A Wowza Community discussion reports that a configured Stream Target may resume broadcasting when its named source returns, but this is community guidance, not a guarantee for every Engine version or configuration. Treat resumption as something to confirm, not something to assume.
If you operate a recorded class or lesson stream, separate source recovery from picture-quality work. The workflow for setting video quality for a recorded YouTube class stream concerns the picture you send; it is not a substitute for checking whether the source is still connected to Wowza.
Read Waiting, Active and Error accurately
Before changing anything, confirm that Stream Targets are enabled for the application and that the individual target is enabled. Then interpret the displayed state in context. Wowza's current guide defines Waiting as an enabled target that is not yet pushing because its source is disconnected or the target connection is still initialising. Waiting alone does not show that a restart is needed.
Active means Wowza has connected and is actively pushing to the destination. It is useful evidence that the outgoing connection is working from Wowza's perspective, but it is not end-to-end proof that the intended YouTube event is showing the feed. Check the event preview as well, particularly if viewers report a blank or stalled broadcast.
Error means Wowza could not connect to the YouTube destination. If the input is also absent, fix the source first. If the input remains Active while the target is Error, focus on the target configuration, destination availability and logs. Avoid treating a temporary transition as a persistent failure until you have checked the relevant states again.
A simple sequence helps prevent misdiagnosis: input absent, restore the publisher; input Active and target Waiting, check configuration and allow initialisation; input Active and target Error, investigate the outgoing connection. This is a decision aid, not a promise that each state has only one possible cause. Record state changes with timestamps, since a short-lived Waiting state followed by Active is different from Error that persists.
If the source is active, inspect the target
Compare the target's destination with the current YouTube Live Control Room event. Check the destination host and application, and confirm that the configured stream key or stream name belongs to the event you intend to use. Wowza describes its YouTube target as an RTMP connection, normally using port 1935, with destination details that include the host, application and generated stream key or name. Keep the key private: do not put it in screenshots, shared incident notes, source code repositories or alert messages.
Do not assume that a key is wrong merely because the target is in Error. Check for a copied value with an extra space, a key rotated since the target was configured, a different selected event, or a destination that is currently unavailable. Make changes only after comparing the target with the active event, and preserve the previous configuration securely so you can see what changed. If the value is uncertain, use the current event details rather than relying on an old note.
Repeated connects and disconnects can also point to a persistent ingest or media-format issue. YouTube's live encoder settings guidance recommends a two-second keyframe interval and says not to exceed four seconds. It also lists supported video and audio options and recommends constant bitrate encoding. These are format checks, not a reason to repeatedly restart a target: if the source is sending a format YouTube cannot use reliably, correct the encoder settings and then test again.
For the documented Wowza YouTube workflow, Wowza states that the video stream must include audio. If a source is video-only, consult the current Wowza guide for its audio-track guidance rather than repeatedly retrying a target that will keep receiving the same unsuitable feed. The key point is to distinguish a configuration fault from a transient connection fault before automating a restart.
Review logs and YouTube Live Control Room
Use the Wowza logs around the recorded failure time to establish whether the target attempted to connect, what state change followed, and whether the same error repeats. Compare those entries with the incoming stream's status and throughput. A log line is evidence to investigate, not a diagnosis by itself; match it against the target configuration and the time shown in Live Control Room.
In YouTube Live Control Room, open the event corresponding to the destination configured in Wowza. Check whether YouTube shows an incoming preview and whether its ingest feedback indicates a problem. A target marked Active means Wowza reports that it is pushing, while the event preview helps check whether YouTube is receiving the intended feed. If you need to test playback without exposing it publicly, the steps for testing a YouTube stream privately can help you plan a controlled check.
Use the combined evidence to choose the next action. If the input is inactive, repair the publisher. If the input is Active but the target is Error, verify the destination and review the connection failure in the logs. If the target is Active but the preview is missing, check the event selection and YouTube ingest feedback before triggering another restart. If both the target and preview recover, record what changed so you can distinguish a genuine fix from a temporary recovery.
Use a bounded REST API retry, not a loop without limits
API automation may be useful when monitoring has confirmed that the source is Active and the target has a persistent destination-side Error. However, the available documentation does not establish one target-restart endpoint or script that works across all Wowza Streaming Engine versions. Check the REST API reference for the exact installed version and verify the relevant operation in a test environment before relying on it for a live channel.
Design a recovery process around conditions, limits and a human hand-off. The monitor should confirm the expected source is present and Active, check that the target is in Error rather than merely Waiting, record the current state and time, then attempt only the version-appropriate action. After the attempt, it should check the target and YouTube preview again. If the target does not recover within your chosen operational window, stop retrying and alert an operator rather than continuing indefinitely.
Choose a retry limit and a delay that suit your channel and the API's behaviour; the research does not establish universal values, so do not copy arbitrary timing into production. Use backoff rather than rapid repeated calls, and make sure the monitor cannot start overlapping retries for the same target. Log the outcome without logging the stream key. Send an alert that identifies the application, target, observed state and relevant log time, but not sensitive credentials.
A useful comparison is not between brands but between recovery methods:
| Situation | Sensible recovery | Why |
|---|---|---|
| Source missing or inactive | Restore the publisher, then verify input and target | A destination retry cannot supply missing video |
| Target Waiting while source is returning | Observe and recheck the state | Waiting can be normal while the source or connection initialises |
| Source Active and target Error | Diagnose destination, then consider a bounded, version-specific API retry | The outgoing target is the confirmed problem area |
| Repeated failure after limited attempts | Stop automation and alert an operator | Repeated retries can hide a persistent configuration or format fault |
A reboot, scheduled restart or target edit is not a universal remedy. Each can add disruption or obscure the original cause, and none should replace checking the input, target state and logs. If the failure recurs, capture the evidence and consult the documentation or support for the installed Engine release before changing the recovery logic.
Verify recovery and watch for recurrence
Do not close the incident when a restart request succeeds. Confirm the incoming stream is Active, the Stream Target is Active, and YouTube Live Control Room shows the intended event receiving a preview. Check that the picture and sound are present. Wowza's guide recommends checking both incoming stream detail and the YouTube event preview, which gives you evidence on both sides of the hand-off.
Watch the stream long enough to see whether the target remains connected, rather than relying on a single status refresh. If it drops again, compare the new timestamps and states with the first failure. A target that briefly becomes Active and then returns to Error needs a different diagnosis from a source that vanishes and comes back. Do not claim that a retry has fixed the problem until the checks remain sound.
For an always-on channel, make the recovery record useful to the next person on duty. Note the Engine version, application and target names, the source state, target transitions, relevant log messages and the YouTube preview result. Exclude credentials. If a format problem is suspected, document the encoder settings you checked, including audio presence and keyframe interval, so the same checks are not repeated without purpose.
StreamNeo can remove the need to keep a personal computer running a file-based YouTube loop, but it does not repair a Wowza target or replace diagnosis of a Wowza deployment. For a channel whose recurring burden is keeping a local machine on and restarting a video broadcast, moving that file-based job away from the computer can address that specific operational chore; it is not a fix for a camera, encoder or YouTube event problem.
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
Will a Wowza Stream Target restart itself when the source returns?
It may resume when its configured source reappears, according to a Wowza Community report, but that is not a cross-version guarantee. Check that the input is Active, then verify the target state and YouTube preview before treating the channel as recovered.
Does Waiting mean I must restart the target?
No. Wowza defines Waiting as an enabled target that is not yet pushing because the source is disconnected or the target connection is initialising. Check the input and allow for initialisation before deciding whether intervention is needed.
What should I do if the source is Active but the target is in Error?
Check the target's destination details against the current YouTube Live Control Room event, then review Wowza logs and YouTube ingest feedback. If the failure is confirmed as target-side, consider a monitored, limited retry using the REST API documentation for your installed Engine version; do not assume a generic endpoint will work.
Can I run a script that retries forever?
An unbounded loop is not a safe recovery plan: it can conceal a persistent key, destination or media-format problem and may keep issuing actions without useful evidence. Set a retry limit and backoff, log state transitions without credentials, and alert an operator if the target remains in Error.