If AWS Elemental MediaLive reports an RTMP output error while you are sending a stream to YouTube, first work out whether MediaLive cannot connect to the destination or YouTube has received the stream and reported an ingest problem. Those are different stages, so a connection alert is not proof that your video or audio settings are wrong.
Start with the exact alert text and the output group that raised it. Then compare MediaLive’s destination details with YouTube Live Control Room; only investigate encoding settings once YouTube is receiving the stream and its stream-health messages point to a format issue.
Find the exact error and its location
Record the full message, the time it appeared and where you saw it: MediaLive channel alerts, output status, or YouTube Live Control Room. If you have logs or a screenshot, redact the stream key and other credentials before sharing them. A stream key grants access to your broadcast, so it should be handled like a password.
The wording matters. AWS documents alert 6018 as a failure to connect to an RTMP endpoint. YouTube’s encoder guidance, meanwhile, includes messages such as “failed to connect to server — connection timed out” and “the RTMP server sent an invalid SSL certificate”. A message from YouTube about bitrate or keyframes is a different kind of evidence: it means the receiving service is reporting an issue with the incoming stream, not necessarily that the endpoint is unreachable.
Also identify which MediaLive output group and destination are involved. AWS lists different alerts for different output problems, including failed writes. Do not collapse an output failure, a connection alert and a YouTube stream-health warning into one diagnosis. In a standard MediaLive channel, AWS says two destinations are required; a single-pipeline channel requires one. Check the configuration for the channel type you actually use rather than assuming one destination count applies to both.
If you need a reference for what the encoded stream is intended to look like, keep that separate from connection diagnosis. A guide to YouTube bitrate for a 1080p 30fps playlist can help when YouTube flags the received video, but it cannot establish why MediaLive failed to contact an endpoint.
Decide whether this is connection or ingest
Think of the path in stages. MediaLive must reach the configured destination and establish the connection. YouTube must then receive the stream and evaluate its audio and video. A fault in the first stage prevents the second stage from providing useful compatibility feedback.
| What you can see | Likely diagnostic stage | Check first |
|---|---|---|
| MediaLive alert 6018 says it could not connect to its endpoint | Connection and destination | Address, protocol, port, application and stream name, credentials, network path |
| YouTube says the encoder failed to connect or timed out | Connection and destination | Current ingest URL, RTMP/RTMPS selection, port and outbound reachability |
| YouTube Live Control Room receives a stream but reports codec, bitrate or keyframe warnings | Ingest compatibility | The specific stream-health message and the settings it names |
| Video or audio looks wrong after YouTube has received it | Ingest and presentation | Stream health, audio/video layout, source and encode configuration |
This distinction prevents a common waste of time: lowering bitrate or changing resolution when no connection has been made. Those settings matter when YouTube is examining incoming media. They do not, on their own, correct a mistyped address, an unsuitable protocol, a wrong port or a blocked network route.
AWS’s RTMP output guidance says that you and the downstream system operator must agree on the destination for each output. For a YouTube stream, treat that agreement as a field-by-field comparison with YouTube’s current Live Control Room details, not as a one-time assumption based on an old saved profile. Review the AWS MediaLive RTMP output documentation alongside the current values in your channel.
Diagnose MediaLive alert 6018
Alert 6018 has a specific meaning: MediaLive is configured to send RTMP output but was not able to connect to its endpoint. Begin with the destination and connection path. The alert does not say that YouTube has rejected the video encode, and it does not identify which field or network component is responsible.
Use a short, ordered check rather than changing several things at once:
- Open the affected MediaLive output and confirm which destination raised the alert.
- Compare its server address and protocol with the current YouTube ingest details.
- Check the port, application or stream name, and any required authentication details against the destination information you are meant to use.
- Confirm that the channel’s required number of destinations is configured for its pipeline type and that each destination is populated correctly.
- If the values match, investigate whether the AWS deployment can make an outbound connection to that destination and whether the destination is available.
Keep a note of each value before editing it. If an alert begins after a configuration change, compare the last known working destination with the present one. Avoid copying a stream URL or key into a ticket, shared document or public screenshot; redact sensitive parts while preserving enough non-secret context for your own comparison.
A network issue can sit outside the encoder fields. A firewall, routing rule or destination-side problem may prevent a connection even when the address looks correct. There is no universal firewall rule to prescribe from the error alone: the route and account setup vary, and the available alert does not reveal every point where delivery can stop. Use the relevant AWS operational information and your network owner’s records to narrow the path instead of making broad changes without evidence.
Check the YouTube ingest URL and protocol
Get the current server URL and protocol from YouTube Live Control Room for the stream you intend to use. Compare those values with the MediaLive output configuration character by character, including any path or application name. Do not assume that an older saved URL, a URL from another stream or a previous event is still appropriate.
YouTube recommends RTMPS for secure ingest. If you have selected RTMPS, confirm that the MediaLive output is configured for that protocol and that the URL is the corresponding secure ingest destination. If your workflow is configured for RTMP, do not simply substitute a secure URL without checking that the output configuration supports and selects the matching protocol. Protocol and destination must agree at both ends.
YouTube’s guidance for a connection timeout is to verify the URL and confirm that the encoder supports RTMPS when using it. For an SSL certificate error, its checks include verifying that the protocol and server are RTMPS and, if needed, specifying port 443. Follow the current wording and instructions in YouTube’s RTMPS troubleshooting guidance; do not interpret the mention of a port as a universal fix for every timeout or certificate message.
For a managed AWS channel, make sure the relevant output fields actually expose the values you intend to use. If MediaLive’s configuration presents separate fields for server address, application or stream name, credentials, or port, compare each one with the destination details rather than treating a single “URL” field as the whole connection. AWS documents that destination details such as protocol, address, port and stream name need agreement with the downstream system.
Verify the stream key and Live Control Room state
YouTube’s troubleshooting steps for an encoder that will not start include retrieving a stream key from Live Control Room and updating the encoder. Confirm that the key belongs to the intended stream and that the selected stream is in a state where you can send to it. A key that was copied from an older setup or another channel can look like a connection fault from the operator’s point of view, even though the remedy is to correct the destination credentials.
Never paste the key into a public article, support forum, screenshot or unredacted log. If you believe a key has been exposed or is no longer wanted, YouTube documents a reset process; once a new key is generated, update the MediaLive configuration that uses it. Do not reset a key casually while a working broadcast depends on it, because the encoder must be updated to the new value. See YouTube’s guidance on stream keys for the current steps.
Check Live Control Room while MediaLive is attempting to connect. Does YouTube show an incoming preview or stream-health status, or does it remain waiting for data? The answer helps place the fault. No incoming stream keeps the focus on endpoint details, protocol, authentication and network reachability. An incoming stream accompanied by an explicit format warning gives you a reason to inspect the encode.
If you have more than one MediaLive destination, keep each destination paired with its intended YouTube configuration. A correct key at one destination does not prove that another output has the same key or endpoint. Compare each output independently and avoid assuming that a primary and backup configuration are interchangeable without checking YouTube’s failover requirements.
Investigate SSL certificate and timeout errors
The phrase “the RTMP server sent an invalid SSL certificate” directs attention to secure connection setup. Confirm that the output is using RTMPS and the intended secure server. If the configuration calls for a port, check whether port 443 is required by the current YouTube instructions and whether the output is actually set to use it. A certificate warning is not a bitrate or resolution warning; changing video parameters does not address the certificate presented during connection setup.
For “failed to connect to server — connection timed out”, verify that the destination URL is current, the selected protocol matches it, and the encoder supports RTMPS if that is the protocol you are using. If all destination fields agree, move to reachability: can the AWS channel’s network path send traffic to that destination, and is the destination responding? The timeout alone does not identify whether the delay lies in routing, a firewall, destination availability or another part of the path.
YouTube recommends testing outbound internet when the encoder’s local output looks and sounds healthy. In MediaLive, use the channel’s alert and available operational information to narrow where delivery stops. If a network administrator manages the route or egress rules, give them the timestamp, affected output, destination hostname or address as appropriate, protocol and port. Do not send the stream key as part of that diagnostic hand-off.
A connection alert is not a reason to re-encode the programme at a lower quality as a first response. If the connection later succeeds and YouTube reports a media warning, you can then make a targeted change and retest. This keeps the diagnosis legible and avoids making an unrelated change that masks the original symptom.
Check stream health after YouTube receives media
Once Live Control Room shows that YouTube is receiving the stream, read its stream-health messages before touching MediaLive’s encode. YouTube’s live error guidance covers video and audio codecs, bitrate, sample rate, the number of audio or video streams, channel count, scan type, resolution, frame rate, keyframe frequency and mismatches between primary and backup streams. Each message points to a different property; correct the one YouTube identifies, then check whether the warning clears.
YouTube lists RTMP and RTMPS as streaming protocols and supports H.264, H.265 (HEVC) and AV1 video with RTMP/RTMPS. Its encoder settings page also lists AAC or MP3 audio, up to 60 frames per second, constant bitrate and a recommended two-second keyframe interval that should not exceed four seconds. Advanced recommendations include square pixels, progressive scan, 44.1 kHz stereo audio and 128 Kbps stereo audio. Consult the YouTube live encoder settings and its error message for the selected codec and resolution; do not treat one bitrate as suitable for every stream.
For context, YouTube’s current H.264 table recommends 14 Mbps for 1080p at 30 fps and 17 Mbps for 1080p at 60 fps; for 720p it recommends 8 Mbps at either 30 or 60 fps. The table also gives minimums of 5 Mbps for 1080p at 30 fps, 6 Mbps for 1080p at 60 fps, and 3 Mbps for either listed 720p frame rate. These figures are tied to YouTube’s stated H.264 resolution and frame-rate context, not a diagnosis for alert 6018. Check the live table for the current recommendation and the codec you actually use.
If you send primary and backup streams, YouTube says their settings must match for failover, including resolution, codec, interlacing, profile, bitrate, frame rate, keyframe frequency, audio sample rate, channel count and audio codec. A mismatch becomes relevant when YouTube reports it or when failover behaviour is under review; it is not evidence that a destination connection failed.
For a broader view of choosing a continuous workflow, compare an encoder-based channel with a playlist approach for a 24/7 lofi station. If you are weighing where the encoder runs, the practical trade-off is discussed in running an online radio stream from a low-power PC. Neither workflow choice replaces reading the error at the stage where it occurs.
Retest and confirm stream health
Test before the event rather than waiting for the scheduled broadcast. YouTube recommends a test with audio and movement similar to the real stream, followed by monitoring stream health and messages during the event. A static title card may not exercise the same audio, motion or encode behaviour as the programme you intend to run, so choose a sample that resembles the actual content.
Change one relevant item at a time. After correcting an endpoint, protocol or key, check whether MediaLive establishes the connection and whether Live Control Room begins receiving data. If it does, inspect YouTube’s stream-health messages. If YouTube still does not receive a stream, return to connection checks rather than changing codec or bitrate without an ingest warning.
Keep a concise record of the alert text, output destination, time, change made and result. This makes a later recurrence easier to compare and helps distinguish a connection problem from a new media warning. Do not record the unredacted stream key. During a live event, watch both MediaLive’s output status and YouTube’s stream-health information; each reports a different part of the delivery path.
If your broader requirement is simply to keep a prerecorded video on air while your local computer is off, a hosted workflow can remove the need to keep a desktop encoder open; for example, the practical differences when a browser-based stream stays open are worth understanding before choosing a setup. That is a workflow choice, not a cure for an AWS destination error. When MediaLive is required, use its exact alert and destination configuration to troubleshoot the channel in front of you.
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 alert 6018 mean YouTube rejected my video settings?
No. AWS defines alert 6018 as MediaLive being unable to connect to its configured RTMP endpoint. Check the destination, protocol and connection path first; use YouTube’s stream-health messages to diagnose media settings after it receives the stream.
Should I lower the bitrate when MediaLive cannot connect?
Not as a first response. Bitrate is relevant when YouTube receives the stream and reports an ingest or quality warning, but it does not correct a wrong URL, key, protocol or unreachable endpoint. Change settings in response to the specific error you can observe.
What should I do about a YouTube RTMPS certificate or timeout message?
Verify the current ingest URL and that the configured protocol is RTMPS when using the secure endpoint. For certificate errors, check YouTube’s current guidance on the server and port; for a timeout, also investigate outbound reachability if the destination values match.
How can I tell whether the stream is reaching YouTube?
Look in Live Control Room for an incoming stream or preview and read the stream-health messages. If YouTube is waiting for data, stay with endpoint and network checks; if it reports codec, bitrate or another media issue, investigate the property named in that message.