To limit bandwidth use for a 24/7 YouTube stream on Hetzner Cloud, lower the encoder bitrate to the lowest level that still gives you acceptable picture and sound, then estimate the resulting monthly outgoing traffic. Check the allowance for your actual server plan and location, and monitor usage: Hetzner’s traffic notices are alerts, not hard stops, and Cloud Firewalls do not impose bandwidth caps.
The key distinction is between the stream’s data rate and the server’s included monthly traffic. A lower bitrate reduces the bytes sent to YouTube over time; notifications help you notice consumption, but do not themselves restrict it. If you need a strict ceiling, do not assume a setting in the Hetzner billing panel or firewall will enforce one.
Understand outbound traffic for a continuous feed
A server that sends an encoder feed to YouTube uses outgoing traffic. Hetzner’s Cloud billing FAQ says incoming and internal traffic are free, while outgoing traffic is counted against the included allowance and may be billed when that allowance is exceeded. Its traffic documentation describes the accounting period as a calendar month.
For a simple one-way setup, the server sends the live video and audio to YouTube’s ingest service. That is the transfer to include in your initial estimate. Viewers who watch on YouTube are not ordinarily receiving a separate copy directly from your Hetzner server: YouTube says it processes live streams into formats for viewers. Count viewer traffic from Hetzner only if your setup actually redistributes the stream from that server, for example to another destination.
Other outbound activity still matters. A server may send backups, updates, monitoring data, or additional copies of the stream. Those uses can consume part of the same allowance, so an estimate based only on the encoder feed is a planning baseline rather than a bill forecast. Make a note of whether the machine has another job before treating all included traffic as available for YouTube.
For practical use, think of bandwidth in two ways. Bitrate is the rate at which the encoder sends data at a given moment; monthly traffic is the accumulated volume over the billing period. A stable but high bitrate can produce substantial monthly volume simply because the feed runs every hour. For background on keeping the signal within YouTube’s expected range, see this guide to bitrate warnings and fixes for Indian internet connections.
Choose an encoder bitrate for the desired quality
The most direct lever is the video encoder’s bitrate. A lower bitrate sends fewer bits each second, reducing the stream’s approximate outgoing volume. It can also reduce image detail or make motion look less clean, especially in scenes with movement, texture, or fine detail. A devotional image with a mostly still background may tolerate a lower setting than a fast-moving local news loop, but test the actual programme rather than relying on the category alone.
YouTube publishes recommendations by codec, resolution, and frame rate in its live encoder settings. Its current guidance should be checked before choosing a target: the recommendation for H.264 is 6 Mbps for 720p at 30 or 60 frames per second, 14 Mbps for 1080p30, and 17 Mbps for 1080p60. For AV1 or H.265/HEVC, the cited recommendations are 6 Mbps for 720p30/60, 10 Mbps for 1080p30, and 12 Mbps for 1080p60. These are recommendations for particular combinations, not a single universal bitrate or a promise that every file will look identical at that rate.
| Example encoder target | YouTube recommended video bitrate | Approximate traffic for a 30-day continuous feed |
|---|---|---|
| H.264, 720p30 or 720p60 | 6 Mbps | 1.944 TB |
| H.264, 1080p30 | 14 Mbps | 4.536 TB |
| H.264, 1080p60 | 17 Mbps | 5.508 TB |
| AV1 or H.265, 1080p30 | 10 Mbps | 3.24 TB |
| AV1 or H.265, 1080p60 | 12 Mbps | 3.888 TB |
The traffic column is a calculation for the stated sustained bitrate over 30 days, not a measurement or Hetzner quote. It excludes extra protocol overhead and any other server egress. If the audio bitrate is not included in the total you use for the calculation, account for it separately. Real calendar months also vary in length.
YouTube recommends constant bitrate (CBR) for encoder configuration and advises testing before going live and watching stream health. Follow the current guidance for your codec and setup. If you are using OBS, a suitable keyframe interval is another part of a reliable encoder configuration; the OBS keyframe interval guide explains that setting in more detail.
A sensible process is to pick the resolution and frame rate your audience needs, choose a supported codec, and test a short stream at the intended bitrate. Look at YouTube’s stream health and the actual picture on a typical phone or television. If you lower bitrate, check for blockiness or lost detail in the parts of the loop with the most motion. The lowest number is not automatically the best choice if viewers cannot comfortably watch the result.
Estimate monthly outgoing usage
Use this formula for a first estimate:
traffic in bytes ≈ bitrate in bits per second × seconds streamed ÷ 8
The division by eight converts bits into bytes. A 30-day month contains 2,592,000 seconds. At 10 Mbps, the calculation is 10,000,000 × 2,592,000 ÷ 8, which gives 3.24 trillion decimal bytes, or about 3.24 TB. At 6 Mbps, the same calculation gives about 1.944 TB.
These figures assume the chosen bitrate is sustained throughout the month. They are arithmetic planning estimates, not measured transfer and not a guaranteed maximum. If the stream is offline for part of a month, the encoder sends less; if the actual bitrate is higher, the feed runs longer, or there is other egress, the total rises. For a closer estimate, use the actual number of days in the calendar month covered by Hetzner’s billing period.
You can also rearrange the calculation to assess a traffic allowance. Convert the remaining allowance to bytes, multiply by eight, and divide by the planned streaming seconds to estimate an average bitrate ceiling. This is only a budgeting exercise: reserve room for overhead and other outgoing tasks instead of planning to consume the entire allowance with video. It does not configure a technical limit on the server.
For instance, compare two candidate settings before committing. A continuous 6 Mbps stream is estimated at 1.944 TB over a 30-day month, while 10 Mbps is estimated at 3.24 TB. The second setting uses about 1.3 TB more over that planning period, before overhead and other traffic. Whether the quality difference justifies that volume depends on your material and viewers, so test rather than choosing a number from the table alone.
Keep units consistent. Mbps describes megabits per second; TB here uses decimal terabytes, so one TB is one trillion bytes. Provider dashboards may display usage in different units or round values, so an exact match between a hand calculation and the console is not expected. Treat the estimate as a way to spot an unsuitable plan or an unexpectedly high target before the month begins.
Check the allowance for the actual plan and location
Do not use a generic Hetzner traffic figure without checking the specific server. Hetzner’s traffic page lists allowances that vary with server family, plan, and data-centre location. Its documentation lists 20 TB for EU CX, CPX, and CAX Cloud servers, while EU CCX plans are listed across a 20–60 TB range depending on the plan. US and Singapore products have lower, plan-dependent ranges. These figures can change, so check the current listing and the allowance shown for your own server before making a budget.
The allowance is not necessarily the same across all of a provider’s products or regions. Identify the family and exact plan in the Hetzner Cloud Console, and note the location where the instance runs. Then compare the applicable allowance against your estimate, including any other outgoing transfers. If the plan is near the estimated requirement, do not assume the traffic notice will prevent overage.
A useful planning margin is the difference between expected use and the included amount. The margin gives room for a longer calendar month, protocol overhead, an encoder setting that varies, or other egress. The appropriate margin depends on how the server is used; no single spare-traffic figure suits every stream. If your calculation leaves little room, lowering bitrate, choosing a plan or location with a suitable allowance, or moving unrelated outbound work elsewhere are options to examine.
The billed usage and the network connection speed answer different questions. Hetzner describes Cloud server bandwidth as not guaranteed and notes an expected range of about 300–500 Mbits, with host connection capacity shared among instances. That is a provider expectation, not a guaranteed sustained rate. It also does not tell you how many terabytes are included in a month. A fast connection does not make a high-volume continuous feed free, and a large allowance does not guarantee a particular stream quality.
If your setup is a prerecorded YouTube loop, keep the focus on the outbound encoder feed rather than the file size alone. The video’s stored size does not directly determine transfer volume once it is being encoded and sent continuously; the outgoing bitrate and runtime drive the estimate. The article on growing a YouTube channel with a 24/7 playlist stream covers the channel context, while the calculation here is about the server’s outgoing traffic.
Set up traffic notices and budget alerts
Use notifications as reminders to investigate, not as protection against charges. Hetzner’s billing documentation says it notifies project owners at 75% and again at 100% of included traffic. The same documentation makes clear that the notifications do not stop or cap use. By the time the second notice arrives, the traffic has already reached the included allowance; more outgoing transfer can still occur.
Cost alerts have a similar role. They can help you notice spending trends, but an alert is not a switch that disables the stream or blocks outgoing packets. Choose notification recipients who will see them, and make sure the relevant account or project owner can act. If an alert is sent to an old email address, it cannot help you respond in time.
Before relying on notices, locate the traffic and billing views in the current console and confirm which project and server they refer to. Console layouts and alert options may change, so use Hetzner’s current documentation rather than an old screenshot or tutorial. If the allowance or budget is shared across multiple machines, understand whether the notification refers to the project total or a particular server before deciding what to stop or investigate.
Write down a response plan for the alert. For example: check the current month’s usage, confirm that the intended stream is running at the chosen bitrate, inspect for unplanned transfers, and decide whether to reduce the encoder setting or stop another job. This makes the notification actionable. It still is not a hard limit, so if crossing the allowance is unacceptable, you need a separate control strategy and should test it before depending on it.
Monitor actual usage over time
A one-time estimate is not enough for an always-on channel. Check usage during the month and compare the trend with the estimate. If a server sends a continuous feed at a stable setting, the amount should rise broadly in line with elapsed streaming time, though dashboard rounding, overhead, interruptions, and other jobs can change the picture.
Keep a small operating record: encoder codec, resolution, frame rate, target bitrate, server plan and location, start date, and usage at regular checkpoints. Note any change to the stream or server workload. This helps explain a jump in usage later. It also makes a plan change easier to assess because you can compare similar periods rather than relying on memory.
If the measured usage is higher than the estimate, check the assumptions in order. Confirm whether the bitrate includes audio, how long the stream ran, and whether the encoder is sending at the expected rate. Then review other outgoing activity from the server, including retransmission destinations or backups. Do not assume viewers watching on YouTube are being served by Hetzner unless your architecture sends them the content directly.
A monitoring routine should include stream quality as well as traffic. A reduction in bitrate can conserve volume but may create visible artefacts or trigger poor stream health. Use YouTube’s live control room and encoder status to verify the stream, and inspect the programme at the target resolution. If the feed is audio-led, as in a radio or bhajan channel, still check that the visual remains acceptable and the audio is clear; the guide to streaming live radio audio with automation discusses the broadcast side of that type of channel.
Avoid waiting until the end of a billing period to compare. A mid-month check gives you time to diagnose a rising trend and adjust the bitrate or workload, although it does not guarantee that you will avoid excess use. For a daily check, record the displayed traffic and compare it with the previous reading; for a less frequent routine, check often enough that the remaining time in the month still allows a meaningful response.
Know what Hetzner Cloud Firewalls do and do not do
A Hetzner Cloud Firewall filters network connections according to rules about traffic and destinations. It is useful for limiting which connections can reach or leave a server, but Hetzner’s Cloud Firewall documentation does not describe it as a speed-control feature or a monthly traffic cap. Blocking a destination is not the same as shaping a connection’s rate.
For a YouTube stream, firewall rules should be considered in terms of whether the server can reach the required streaming service and whether unwanted network connections should be allowed. A rule that blocks the stream destination may interrupt the broadcast, but it is not a measured monthly quota that permits a planned amount and then stops automatically. Do not configure a firewall expecting it to limit usage to a particular number of terabytes.
Traffic shaping and byte caps are different controls. Shaping is intended to constrain a transmission rate; a volume cap is intended to stop or restrict transfer after a defined amount. The official Hetzner notices and Cloud Firewall material described here do not provide those functions for monthly traffic. A separate server-side control may be a technical avenue to investigate, but this article does not verify a particular implementation or recommend it as a tested Hetzner feature. A poorly tested control could also interrupt the live feed.
If your requirement is a strict, enforceable ceiling, be explicit about that requirement when assessing the design. Confirm how the control works, whether it applies to all relevant egress, what happens at the limit, and how it recovers at the next billing period. Test it away from a live channel. Otherwise, the practical managed approach is to choose a conservative bitrate, leave margin against the plan allowance, and monitor usage while accepting that alerts only inform you.
If the recurring task is keeping a video feed running while your own computer is off, StreamNeo removes the need to leave a local machine encoding continuously by turning an uploaded video into a YouTube live stream that can be monitored and restarted if it drops; you still need to choose and check an operating arrangement that fits your traffic requirements.
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 much bandwidth does a 24/7 stream use?
It depends mainly on the sustained bitrate and how long the server sends the feed. As a planning estimate, 6 Mbps uses about 1.944 TB over 30 days, while 10 Mbps uses about 3.24 TB, before overhead and other outgoing transfers. Use the actual calendar month and your own encoder settings for a closer estimate.
Does Hetzner stop traffic when I reach the included allowance?
No. Hetzner’s traffic notifications are notices, not a hard stop; more outgoing traffic can continue after the included amount is reached. Check current billing documentation and plan details, and do not treat a 100% notice as enforcement.
Can I cap outgoing bandwidth with a Hetzner Cloud Firewall?
The documented Cloud Firewall filters network connections; it is not described as a bandwidth shaper or monthly traffic cap. Firewall rules can block a needed destination and interrupt your stream, but do not rely on them to enforce a monthly byte limit.
What should I change first if the estimate is too high?
Check that the chosen resolution, frame rate, and codec suit the content, then test a lower bitrate and inspect the result in YouTube’s stream health view. Recalculate the monthly volume and preserve room for other server egress. If the required quality still exceeds the plan’s allowance, compare an appropriate plan or a different operating design rather than expecting alerts to stop the transfer.