When an Amazon IVS Low-Latency stream buffers or drops, start by identifying who is affected and when the broadcast metrics changed. Check the broadcaster, local network, ingest path, service control plane and viewer playback as separate fault boundaries; a buffering report alone does not identify the cause.
Stream starvation is one specific signal: IVS is receiving fewer bits than the encoder says it should send over a period. It can point to the encoder or the path from it to IVS, but it is not proof that IVS has failed. Use the symptom and session data to choose the next test.
Start with the observed symptom
First establish whether the problem is visible to every viewer, to a particular group, or only on one device. Note the time it began, whether the stream recovered by itself, and whether the live broadcast itself stopped or only playback appeared stuck. Ask a viewer on a different network to check before changing the production configuration.
If several viewers report the same interruption at roughly the same time, look first at the broadcast session: did video bitrate, frame rate or audio bitrate fall, and did IVS report starvation or a stream-health change? A common interruption can be consistent with the broadcaster stopping or sending too little data, since IVS cannot deliver content it is not receiving. It still does not establish the cause by itself.
If one viewer or one network is affected while others continue watching, investigate that viewer's connection, device, selected playback quality and local bandwidth competition. Adaptive bitrate changes or a manually selected high quality may affect playback on a constrained connection. Do not restart a healthy encoder just because one viewer is buffering.
Keep a short incident record: timestamps with time zone, channel and stream identifiers, viewer reports, encoder logs, and the relevant metric or event. A timeline makes it easier to correlate symptoms across the broadcaster and IVS. For a basic explanation of the video rate shown by an encoder, see what frame rate means in live streaming; frame rate is useful context, but bitrate and audio data matter too.
What is stream starvation?
Stream starvation means the service receives fewer bits over time than the encoder indicated it would send. The key phrase is “over time”: an isolated metric fluctuation is not the same as a sustained interruption, and the signal should be read alongside the encoder's output and the rest of the session timeline.
Amazon Web Services lists the encoder, local network conditions and the public internet route to IVS among common causes. A process may be consuming upload bandwidth, the broadcaster may be struggling to produce frames, or the network path may be impaired. A report of buffering downstream is not enough to distinguish those cases from a viewer-side problem.
Treat starvation as evidence about delivery into the service, not a verdict on which component failed. Compare the time of a starvation event with encoder logs and the video, frame-rate and audio metrics. If the encoder reports a healthy output but IVS sees a shortfall, inspect the local network and route next. If output itself becomes erratic, investigate encoder load, source media and broadcaster behaviour before changing network settings.
For a pre-recorded programme, a stopped playlist or stalled file reader can look like a network problem from the audience's perspective. Check whether the encoder is still producing frames and audio rather than assuming the connection is at fault. The article on why OBS can stop playing a podcast playlist is relevant when the source is a local playlist.
How do I monitor stream-starvation events?
Use IVS Stream Health to review the live session and its time series, including video bitrate, frame rate and audio bitrate. CloudWatch provides IVS metrics that you can graph and use for alarms. Session analytics can help with diagnosis while a broadcast is live and with retrospective investigation afterwards. The Amazon IVS monitoring documentation describes the available monitoring options; confirm the current details there when setting up an operational process.
AWS recommends using EventBridge stream-health change events to detect starvation start and end. An event rule can direct an alert to the people responsible for the broadcast, or invoke an appropriate response in your own workflow. An alert tells you that a health condition changed; it does not tell you whether the encoder, local connection or public route caused it.
Set alert conditions against your actual encoder profile and observed healthy baseline, rather than copying a threshold from another channel. A quiet devotional stream and a fast-moving news loop may have different expected patterns. Record what healthy bitrate, frame rate and audio look like for your own output, then investigate departures in context. Avoid treating every brief variation as an incident if the stream remains healthy, or suppressing a sustained loss because a generic threshold was not crossed.
CloudWatch metric resolution and retention follow AWS's documented roll-up schedule, which can affect how much detail remains useful for later review. AWS documentation says IVS CloudWatch statistics are retained for 15 months; consult the current IVS CloudWatch metrics documentation for the current resolution and retention details. This is an AWS-documented service fact, not a guarantee that every detail of every session is retained at the same granularity.
A practical alert should give an operator a timestamp, channel context and a link or instructions for opening the relevant Stream Health view. If the alert fires overnight, the person on duty should be able to tell whether it ended, whether the encoder reconnected, and whether viewers are still reporting a problem. Preserve event and encoder logs according to your own operational needs; an alert without enough context only moves the diagnosis to the next morning.
How do I diagnose stream instability using IVS Stream Health?
Open the affected session and compare the metric lines over the same time range. Look for whether video bitrate falls first, frame rate becomes uneven, audio bitrate disappears, or the measures change together. Correlate that pattern with stream-health events and the encoder's own log. A fall in one measure is a clue, not a diagnosis: for instance, audio disappearing while video continues calls for a different source check than all output collapsing together.
Check the stream-health analytics for encoder configuration, ingest metrics and session events where available. Ask what changed just before the first bad timestamp: an encoder restart, source or playlist change, network activity, firewall update or application deployment. If no such change is known, do not invent one; continue testing the boundaries that the evidence leaves open.
Compare the IVS view with what the broadcaster says it sent. If the encoder output is already low or missing frames, concentrate on the encoder, input and source path. If encoder output looks normal while IVS reports a shortfall, inspect local bandwidth and the route to the service. If IVS receives a stable stream and only a subset of viewers report trouble, shift attention to playback and the viewer's network.
For a recurring issue, save the relevant time series and event times before making a change. Change one setting at a time and note the result. Replacing the encoder profile, moving networks and changing keyframes all at once might stop a symptom, but it also removes the evidence needed to know which adjustment mattered.
Separate encoder and broadcaster issues from network issues
An encoder-side problem is more plausible when its own output becomes erratic, the source stops advancing, or the broadcaster logs show a stall at the same time as the IVS health change. Check CPU or device load, capture input, file playback and the output profile. For a playlist-based broadcast, test a representative segment and confirm that frames and audio continue across transitions; a frozen source can send little useful content even if the network remains connected.
Network trouble is more plausible when the encoder continues producing its expected output but the IVS session shows a receiving shortfall. Check whether other applications or devices are using upload bandwidth. AWS's troubleshooting guidance suggests checking competing network processes and contacting the ISP for diagnostics if local bandwidth or the ISP-to-IVS route appears insufficient. For a fixed broadcaster whose Wi-Fi is unstable, Ethernet is a setup option worth testing, but it does not cure congestion elsewhere on the path.
The required egress path depends on the ingest protocol. AWS lists RTMPS to *.live-video.net over TCP 443, insecure RTMP over TCP 1935, SRT to *.srt.live-video.net over TCP 9000, and WebRTC signalling over TCP 4443 with UDP ephemeral media ports 32768–61000. AWS also says the IVS_LOW_LATENCY IP subnets must be reachable regardless of selected Region because streamers may connect to any subnet. Check the official IVS network requirements and current AWS IP range data before changing firewall rules; live lists can change. The cited requirements do not apply to AWS PrivateLink ingest.
Review keyframe settings only when the session evidence or encoder configuration makes them relevant. AWS's setup guidance identifies a two-second keyframe interval as a standard setting. A one-second interval may reduce latency, but can make adaptive-bitrate resolution changes more frequent and may increase buffering in some conditions. The streaming configuration guidance says not to set keyframes above five seconds because startup latency can rise and segments may lack an IDR/keyframe, risking decode errors or visual distortions. See AWS's IVS streaming configuration guidance before changing a working profile.
If the broadcaster stops sending data, AWS says IVS waits 30 seconds and then disconnects the stream; a reconnect, whether automatic or manual, starts a new stream. This is not an ingestion failover. Verify that the encoder or client has a reconnection behaviour suitable for your operation and test it before relying on it during a live programme. A fixed YouTube-style loop can have different recovery needs from a mobile reporter moving between networks.
Check ingest and service-control-plane signals
Separate the live media path from the control plane used by your application to create, configure or manage channels. If a broadcast is already ingesting and viewers receive media, an application error about channel management does not by itself explain a playback interruption. Conversely, an inability to start or configure a channel can be a control-plane issue even if your broadcaster and local network are healthy.
For an ingest-side symptom, line up Stream Health, ingest metrics, stream events and encoder logs. Check the actual protocol destination and egress rules from the broadcast network; a firewall change or restricted network can block an otherwise sound broadcaster. Do not assume that a successful connection test to some other AWS endpoint proves the required IVS ingest path is reachable.
AWS states that IVS does not provide automated failover for ingestion or transcoding failures. It advises configuring the encoder or client to re-ingest after broadcast failures. That recovery action is different from the service automatically switching to a second ingest or transcoding path, so document what your encoder does and test how a new stream session affects your workflow.
The control plane has a separate regional consideration. AWS says IVS does not natively fail over its regional control plane; an application that needs regional control-plane failover must provide its own application-side logic. AWS does not publish an official recipe for managing regional channel failover, so do not treat a second configured Region as automatic protection. If your application depends on regional recovery, design and validate that behaviour against current AWS guidance rather than improvising during an incident.
If you broadcast with the IVS Broadcast SDK and receive an error, capture the unique broadcast session identifier using the relevant platform API and provide it to AWS Support. Also check the SDK release notes and whether the deployed version is current. The identifier helps support investigate a particular session; it is not itself a diagnosis or a repair. On mobile, the SDK's automatic bitrate adjustment can respond to changing network conditions, but it cannot make an impaired network path disappear.
For a continuous prerecorded programme, distinguish the media-broadcast platform from the intended destination. StreamNeo can remove the need to keep a local computer running to feed a file into a YouTube channel, but it does not operate as an IVS broadcaster or diagnose IVS sessions. If your issue is that a local machine or playlist stops feeding a YouTube live stream, the guide to keeping a single video looping with FFmpeg covers that separate workflow.
Investigate viewer playback reports
Once the broadcaster and IVS session appear stable, compare reports by device, playback quality and network. Ask an affected viewer to try another connection, such as mobile data instead of the same Wi-Fi, and check whether the player is set to auto quality or a manually selected resolution. If only viewers on one ISP or local network are affected, that points to a different boundary than simultaneous reports across unrelated networks, but it is still evidence to investigate rather than proof.
A viewer's available bandwidth can change while the stream itself remains steady. Other household devices, a busy shared connection or ISP congestion may compete with video playback. Adaptive bitrate can select a lower resolution as conditions change; forcing a higher quality can make buffering more apparent on a limited connection. Ask for the approximate time and what quality or device was in use, then compare that report with the broadcast health timeline.
When all viewers report buffering at the same point and IVS shows that the broadcaster stopped sending, focus on the broadcast recovery path. When IVS metrics remain steady and reports cluster around one device or network, avoid resetting the channel as a first response. This distinction saves time and avoids turning an isolated playback issue into a broader interruption.
Keep the viewer's report specific: device and app or browser, network type, selected quality if known, start time, and whether playback recovered. Do not ask viewers to change several settings and then infer a cause from the result. A small, consistent set of observations is more useful than a collection of unrecorded experiments.
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 stream starvation mean Amazon IVS is down?
No. Starvation describes IVS receiving fewer bits than the encoder indicated it would send over a period. AWS lists encoder, local network and public-internet route issues among common causes, so check the session evidence before assigning a service fault.
Does IVS automatically fail over if ingest or transcoding stops?
No. AWS says it does not provide automated failover for ingestion or transcoding failures. Configure and test the broadcaster's reconnection behaviour, and treat application-side control-plane regional recovery as a separate design requirement.
Which IVS metrics should I check first?
Start with video bitrate, frame rate and audio bitrate in Stream Health, then correlate the time series with stream-health events and encoder logs. CloudWatch and session analytics can support alerting and later investigation; a metric change is a clue to test, not a cause by itself.
What should I send AWS Support for a Broadcast SDK error?
Capture the unique broadcast session identifier using the relevant platform API and include it with the error details and timing. Check the SDK version and release notes as well; the identifier helps support investigate the session but does not resolve the problem on its own.