Wowza Streaming Engine is the software that receives and manages a live source; Wowza Streaming Engine Manager is the browser interface you use to configure and monitor an Engine instance. You can connect a compatible camera or encoder you already own: a new encoder is not automatically required.
The practical sequence is to confirm you are working with Engine, open its Manager, prepare a live application, connect the source, and verify both incoming status and playback. Keep Engine Manager distinct from Wowza Video’s Stream Health Monitor, which belongs to a different product.
Confirm you are using Wowza Streaming Engine
Before following an Engine workflow, check the product and the instance you have access to. Wowza Streaming Engine (WSE) is deployed as an Engine instance that you or your organisation manage. Engine Manager is its browser UI for configuration and operational monitoring. Wowza’s overview of configuring and managing live streams describes the available management routes, including Manager, XML configuration and the REST API.
Do not confuse this with Wowza Video. Wowza Video is a separate product surface, and its Live Stream Details page has a Stream Health tab. That page reports inbound bitrate, frame rate at the transcoder and keyframe interval for Wowza Video streams. Those metrics and that page are not proof that the same controls appear in Engine Manager. Wowza’s Wowza Video live stream details documentation describes that product’s view; check the documentation for your own product and version before relying on a particular metric.
This distinction matters when diagnosing a problem. A stream that is not listed as incoming in Engine needs source, application, or Engine-side investigation. A stream in Wowza Video should be checked in its own controls. Do not start by searching for a Video-only page inside Engine Manager.
Also confirm the Engine instance is running and that you have access to its Manager login. The exact installation, licensing and configuration depend on the deployment; the steps here assume you already have an accessible Engine instance. If your task is to publish to YouTube rather than to receive a source in Engine, remember these are separate destinations and workflows. For a broader view of what a source can do when it fails, see what happens when a YouTube live stream’s encoder loses power.
Open Streaming Engine Manager
Manager is the browser UI for an Engine instance. Wowza documents the default address form as http://[wowza-ip-address]:8088/enginemanager; use the address and access details supplied for your own deployment rather than treating that example as a public server address. The Engine instance must be running before you sign in, and Wowza recommends using a modern browser. See its guide to finding your way around Streaming Engine Manager for the current interface description.
The interface groups controls by scope. Server and Virtual Host views help you inspect the instance and its virtual host; application views relate to a particular application. The home view can show aggregate source and playback connections and resource-use categories such as CPU, Java heap, memory and disk. Server Monitoring and Virtual Host Monitoring provide scoped connection, throughput and uptime views; Application Monitoring focuses on the selected application’s connections, throughput and uptime.
Use the scope that matches the symptom. If every application appears affected, start with the server or virtual host view. If one live application is not receiving a source, inspect that application and its Incoming Streams. This saves time compared with treating every status indicator as if it referred to the same layer.
For a one-off application setup or a quick visual check, Manager is usually the most direct route. XML configuration is useful when you need direct file-level changes, while the REST API can suit repeatable management or integration work. These are practical ways to choose a workflow, not a ranking from Wowza. If you use an API example, verify its compatibility with the Engine version you actually run; Wowza’s cited live-source REST guide requires Engine 4.3.0 or later.
Connect a compatible camera or encoder
A camera or encoder is the live source that publishes to Engine. First check what output protocols your existing equipment supports and whether that protocol fits the application and playback types you intend to use. Wowza documents integrations with some common encoders, while other devices can be configured manually. If your current camera or encoder can publish in a supported way, there is no reason to buy a replacement solely to follow this guide.
In the source device’s connection settings, you may need the Engine address, the streaming host port, the application name and the stream name. RTMP- and RTSP-based publishers in the documented workflow require source username and password by default when source authentication is enabled. Those credentials are case-sensitive. Do not assume every protocol uses that same authentication mechanism; check both the source and Engine configuration for the protocol you are using.
Wowza identifies TCP port 1935 as the default streaming host port, and it can be changed in Virtual Host Setup. Treat that as a documented default, not a promise about your deployment: confirm the configured port and network access with whoever manages the instance. If a firewall or routing rule blocks the source from reaching the host, correct that path rather than changing unrelated playback settings.
An existing encoder’s menus may use different labels for server, application and stream name. Use the values configured for your Engine application, and avoid copying credentials or server addresses from another system. If Manager provides an integration for your device, it can help with connection setup; otherwise enter the values manually according to the encoder’s own instructions. For a source-side primer on choosing and checking equipment, the mobile streaming setup and troubleshooting guide offers a useful checklist, though the precise Engine fields still come from your deployment.
Configure and start the live stream
Create a live application before publishing. In that application’s Setup page, choose playback types that match how viewers will receive the stream. Wowza explains that these types allow source transmuxing to formats and protocols including MPEG-DASH, HLS, RTMP and RTSP/RTP. Choose what your intended players need rather than enabling every option without a reason.
Review Playback Security in the application settings in light of the audience and playback path. Access controls affect who can view the output, so do not treat unrestricted client access as a universal default. If you change playback-security settings, the documented workflow calls for restarting the application for the changes to take effect. Plan that restart rather than making it during a broadcast if viewers rely on the service.
Once the application exists, configure the camera or encoder with the matching host, port, application name and stream name, along with any source credentials required by the protocol and configuration. Start publishing from the source. At this stage, the source connection is only one half of the job: a connection can be accepted while a viewer URL or playback configuration still needs attention.
A useful way to keep the setup legible is to write down the application name, stream name, configured port, protocol, and whether source authentication is enabled. Keep passwords out of shared notes. If you change one field, you can then compare the source’s settings with the intended Engine values rather than guessing which part drifted.
Check whether the stream is active
In Manager, open the live application’s Incoming Streams view after starting the source. Find the stream by its configured name and check that its status is shown as Active. If it is absent or not active, do not move directly to viewer troubleshooting: first verify the source is publishing to the correct Engine address, port, application and stream name.
Open the stream entry to inspect its uptime, network throughput and other published-stream information. These details help establish whether Engine is receiving a source and whether data is continuing to arrive. An Active status is a source-ingest check, not a guarantee that every viewer can play the output.
Use Test Playback to check the viewer path separately. Select a playback URL appropriate to the playback type enabled for the application, then test it with a suitable player or browser. A secure playback URL is appropriate only if SSL/TLS streaming is configured for the deployment. If the incoming source is active but playback fails, examine the selected playback type, URL, security configuration and player support as separate items.
This division between ingest and playback makes diagnosis more precise. “The encoder is connected” means Engine is receiving the source; “a viewer can play it” means the output path also works. For a broader checklist on production habits and audience-facing checks, see live streaming tips for a better broadcast.
Monitor connections and stream status
Use monitoring views according to the question you are trying to answer. Server Monitoring helps you see instance-level connections, throughput, uptime and resource consumption. Virtual Host Monitoring narrows those views to a virtual host. Application Monitoring shows connections, throughput and uptime for a particular application. Incoming Streams is the most direct place to inspect a specific published source.
| Question | Where to look in Manager | What it helps establish |
|---|---|---|
| Is the Engine instance receiving sources and serving playback connections overall? | Home or Server Monitoring | Aggregate connection and resource context |
| Is a particular virtual host carrying traffic? | Virtual Host Monitoring | Scoped connections, throughput and uptime |
| Is this live application receiving activity? | Application Monitoring | Application-level connections, throughput and uptime |
| Is this named source publishing? | Incoming Streams, then the stream entry | Active state, uptime and source throughput |
| Can a viewer receive this output? | Test Playback | Whether the selected playback URL works in a suitable player |
Treat these views as related but not interchangeable. A server-level connection count is not the same as a source-specific status, and an active source is not the same as a successful viewer test. When you monitor an always-on stream, record which view you checked and at what point in the troubleshooting process; that makes handovers clearer, especially when someone else manages the source or network.
For repeatable operations, you can manage Engine through Manager, XML or the REST API. The interface is suitable for visual one-off changes and checks; programmatic calls may suit an integration or repeated task; XML gives direct configuration control. The right method depends on how your Engine deployment is managed. Avoid copying API examples without checking version support and access controls for your instance.
The Wowza Video Stream Health Monitor is not another Engine Manager monitoring tab. In Wowza Video, its Live Stream Details view exposes inbound bitrate, frame rate at the transcoder and keyframe interval, and its session history covers the previous 90 days, as documented by Wowza in 2026. Keep those product-specific capabilities scoped to Wowza Video; do not infer that Engine Manager offers the same screen or history window.
Troubleshoot common source or ingest issues
If the stream does not appear in Incoming Streams, check the source settings against the application you created. Confirm the address, port, application name and stream name, then verify that the source is actually sending. Where the source uses RTMP or RTSP authentication, re-enter the configured source credentials carefully because they are case-sensitive. Do not apply that same credential assumption to other protocols without checking their setup.
If the source cannot reach Engine, check the configured streaming host port and network path. TCP 1935 is Wowza’s documented default, but an administrator may have configured a different Virtual Host port. Ask the instance owner to confirm the current value and relevant firewall or routing rules. Changing the encoder to a different port without checking Engine can make the mismatch worse.
If the stream appears but does not show Active, inspect the source’s own connection status and the Engine-side stream entry. Confirm that the device is still publishing and that its selected protocol is supported by the application configuration. If a source was previously working, compare recent changes in credentials, network rules or application settings rather than replacing equipment immediately.
If the stream is Active but playback fails, test the playback URL generated for the enabled type. Check that the chosen player supports that type and that the URL corresponds to the correct application and stream. For secure URLs, confirm SSL/TLS is configured. If you changed Playback Security, make sure the application restart required by the workflow has occurred.
If the symptoms are broader than one source, use Server or Virtual Host Monitoring to see whether other connections and resources are affected. If only one application is involved, focus on its application settings and incoming source. For a separately published YouTube output, a loss of power or host interruption creates a different failure mode; the guide to a looping YouTube stream after encoder power loss explains that boundary. Do not assume an Engine source issue and a YouTube ingest issue share a single remedy.
A sensible troubleshooting order is to confirm the product, application, source settings, source credentials if relevant, network reachability, Incoming Streams status, and then Test Playback. This order moves from the publisher toward the viewer and prevents a playback symptom from being mistaken for a source failure.
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 connect an encoder to Wowza Streaming Engine?
Create a live application, check the playback types and source-authentication settings, then enter the Engine address, configured port, application name and stream name in the encoder. RTMP- and RTSP-based sources may require case-sensitive source credentials in the documented workflow. A compatible camera or encoder you already have may be sufficient.
How can I tell if my live stream is active?
Open Incoming Streams for the application and check that the named source is listed as Active. Open its entry to inspect uptime and throughput, then use Test Playback to check a viewer URL separately. Active ingest does not by itself confirm successful playback.
Where do I monitor connections and server load?
Use Server Monitoring for instance-level context, Virtual Host Monitoring for a particular virtual host, and Application Monitoring for one application. Open Incoming Streams for a source-specific check. These views answer different operational questions and should not be treated as interchangeable.
Is Stream Health Monitor part of Engine Manager?
No. Wowza’s documented Stream Health Monitor is on Wowza Video’s Live Stream Details page, a different product surface. Check the documentation for the product you use rather than expecting its metrics or session history in Engine Manager.