Netflix's real record is 65 million streams, and that w...

Every night, inside more than a thousand ISPs, a server that Netflix gave the ISP for free downloads tomorrow's viewing. It does this in a 12-hour window that defaults to 2AM to 2PM local time, at no more than 1.2 gigabits per second, moving up to 6.5 TB before the window closes (Open Connect, Fill patterns). The ISP cannot make it go faster; Netflix's partner FAQ answers that request with "No, this is not possible" (Open Connect FAQ). What goes into the download is decided by yesterday's bytes: an asset's popularity is total bytes streamed from it divided by its size, smoothed over several days and ranked per region (Content Popularity for Open Connect, June 20, 2017). By the time you press play that evening, the file is already on a disk a few router hops from your house. The request is the last step.

That sentence is the thesis of a member-only Medium post by The Speedcraft Lab, published July 10, 2026 and edited July 15, whose subtitle reads "Most of the hard problem is solved before you press play." (Medium). I read it as the prompt for this piece, and it is right about on-demand video. Its headline says 260 million concurrent streams, which is a membership count, and as far as I could read it, it never gets to live, or to the fact that the night its own example was set is the night Netflix buffered. Those two omissions are this article. After them comes the part a one-person site can copy, priced: a CDN bill that starts at $0, video from $6 for the first thousand minutes stored and watched (Cloudflare Stream), and one cache header that, set wrong, hid a deploy on a client site of mine for what would have been a year.

260 million is memberships. 65 million is Netflix's record, and it buffered.

Netflix's Q4 2023 shareholder letter, dated January 23, 2024, reports 260.28 million paid memberships at the end of 2023, and its prose says "over 260 million households", which is where the post's member-households wording comes from (Q4 2023 letter); the Q4 2024 letter, dated January 21, 2025, reports 301.63 million and estimates the audience at over 700 million people (Q4 2024 letter). Netflix said on April 18, 2024 that it would stop reporting quarterly memberships with Q1 2025 earnings (Q1 2024 letter); the April 17, 2025 letter is the first without the row (Q1 2025 letter), and the only milestone since is 325 million, crossed in Q4 2025 (Q4 2025 letter). No Netflix document contains 260 million concurrent anything.

The concurrency record is a different number. Netflix's November 19, 2024 release says the Jake Paul vs Mike Tyson fight peaked "at 65 million concurrent streams, with 38 million concurrent streams in the US", with an estimated average minute audience of 108 million from TVision and first-party data, and no mention of buffering (About Netflix). Its engineering blog repeated "a historic peak of 65 million concurrent streams" in December 2025 (Netflix Live Origin), and one April 2026 post says 64 million (The Human Infrastructure). Since March 2026 it is Netflix's record, not the world's: an ICC release dated March 7, 2026 reported "65.2 million peak concurrent viewers on JioHotstar" for the India vs England semi-final played on March 5 (ICC), and News9live, citing the ICC, put the March 8 final at 72.5 million (News9live).

The Medium post's own second paragraph keeps the numbers apart, 260 million households in early 2024 and 65 million streams on one November night (Medium); the headline conflates what the body separates. Its figure of more than 300 terabits per second is 65 million multiplied by an assumed 5 Mbps; Netflix has published no per-stream bitrate for the fight, only "tens of terabits per second" of peak traffic in 2016 (Ken Florance). It also repeats the 17,000 servers in 158 countries figure, which The Verge quoted from a Netflix spokesperson on November 17, 2021 (The Verge); Netflix's own count a year later was 18,000 servers in 6,000 locations across 175 countries (About Netflix, December 14, 2022).

The request is the last step: what an OCA does and does not do

Netflix's Open Connect Overview says an Open Connect Appliance does only two things: report its status (health, learned BGP routes, files on disk) to control-plane services in AWS, and serve content over HTTP or HTTPS when a client asks; it stores no client data, and a steering service in AWS picks the OCAs and generates the URLs the client fetches from (Open Connect Overview). Ken Florance, then Netflix's VP of Content Delivery Product, drew the line in March 2016: everything before you hit play happens in AWS, everything after is Open Connect, then carrying "tens of terabits per second" at peak (About Netflix, March 17, 2016); the rest of the service finished moving into AWS in early January 2016 (About Netflix, February 12, 2016). The dependence runs one way: the deployment guide, last updated August 22, 2025, says that if connectivity to AWS is lost, OCAs stop serving traffic (Deployment Guide). The data plane cannot run without the control plane, and the control plane never touches a video byte.

Netflix provides the appliances at no charge to qualifying ISPs and says it partners "with over a thousand ISPs" (Open Connect), a phrase unchanged on the page since at least May 2020. The current Storage appliance is a 2U box with one AMD processor and Kioxia or Micron SSDs at about 200 Gbps, up to 120 TB and about 400W; the Global appliance for smaller ISPs does about 80 Gbps and 60 TB; both run FreeBSD -CURRENT, NGINX serving the files directly over HTTP, and the BIRD routing daemon feeding the ISP's topology back to AWS (Appliances). On per-server throughput, Drew Gallatin's EuroBSDCon 2021 slides say Netflix had served 200 Gb/s of TLS video from one server since 2020, that software kTLS topped out at 240 Gb/s on memory bandwidth, and that NIC-offloaded kTLS on an AMD EPYC 7502P with 4x100GbE reached about 380 Gb/s (Gallatin, EuroBSDCon 2021). His 2022 deck claims "almost 800Gb/s" since 2021, but the deck itself measures 731 Gb/s, so quote the measurement, not the claim (Gallatin, EuroBSDCon 2022).

The nightly fill: 12 hours, 1.2 gigabits, decided by yesterday's bytes

"Netflix and Fill", by Michael Costello and Ellen Livengood, calls proactive caching "an important difference between our Open Connect CDN and other commercial CDNs" (Netflix and Fill, August 11, 2016). An OCA knows nothing about other OCAs or title popularity. It periodically asks the AWS control plane for a manifest of titles it should hold, requests the delta during its window, and gets a ranked list of sources: peer fill from OCAs in the same cluster or subnet, tier fill from OCAs outside it, then cache fill straight from S3; as members in one time zone start streaming, the window there closes and the pattern continues west (Netflix and Fill).

The ranking behind the manifest is what explainers skip. Popularity is bytes streamed divided by asset size, smoothed over several days rather than copied from yesterday and computed per region; moving most clusters from title-level to file-level ranking in 2016 gave "the same caching efficiency with 50% of storage"; staff sometimes pin an upcoming title high by hand; within a cluster a title is replicated over N servers with N roughly proportional to popularity, and popular files are locked into memory (Content Popularity). Normally only 10 to 20% of the most popular titles are served from memory (Serving 100 Gbps, September 29, 2017).

Fight night is the proof the model holds even while it strains. Kentik's Doug Madory measured Netflix traffic across Kentik customers at almost three times the normal peak in bits per second, and still 69.6% came from embedded caches, 23.9% from private peering, 3.3% from transit and 3.0% from public peering (Kentik, November 21, 2024); on Christmas Day the embedded share was 89.9% (Kentik, January 8, 2025). The 95% figure that explainers repeat as caches inside ISPs is looser. Netflix's Nihit Tandon wrote in June 2018 that close to 95% of traffic is delivered over direct connections between Open Connect and residential ISPs (APNIC, June 20, 2018), and direct connections, like Netflix's own 90% figure from March 2016, include peering at exchanges (About Netflix, 2016). One change deserves a date because it is easy to misdate: the live Fill patterns article now lists "During live events" as a trigger for out-of-cycle fills (Fill patterns), but archived copies from December 25, 2024 through November 18, 2025 list only re-encodes and day-of-broadcast titles (Wayback, November 18, 2025). When the NFL games ran, the partner documentation did not yet list it. Whatever Netflix did internally, the documented change is not a pre-Christmas 2024 fix.

Encoding so the smallest file that looks right is the one that ships

Pre-positioning only works if the files are small enough to fit and to serve. When Netflix deployed H.264 in late 2010 it used one ten-rung ladder for every title, which I read from the table image in the 2015 per-title post (Per-Title Encode Optimization, December 14, 2015):

Bitrate (kbps)	Resolution
235	320x240
375	384x288
560	512x384
750	512x384
1050	640x480
1750	720x480
2350	1280x720
3000	1280x720
4300	1920x1080
5800	1920x1080

Per-title encoding, announced that day by Anne Aaron, Zhi Li, Megha Manohara, Jan De Cock and David Ronca, chooses a ladder per title from trial encodes under two constraints: candidate bitrates sit on a grid roughly 5% apart, and the selected rungs are spaced about one just-noticeable difference apart; Orange is the New Black tops out at 4,640 kbps instead of 5,800, a 20% saving at the same quality, and an episode of BoJack Horseman streams 1080p at 1,540 kbps where the fixed ladder gave 480p at 1,750 (Per-Title Encode Optimization).

Per-shot came next. The Dynamic Optimizer, published March 5, 2018 by Ioannis Katsavounidis, splits a title into shots, encodes each at several resolutions and quantizers, and scores each with VMAF, a metric Netflix built because at about 35 dB PSNR the human scores in its dataset ran anywhere from 10 to 100 (VMAF, June 2016); it then assembles the title one shot at a time at equal rate-distortion slope and aligns keyframes to shot boundaries so the player switches where a change is least noticeable, and on ten titles it saved an average 17.1% bitrate over the best fixed-quantizer encode (Dynamic Optimizer). For 4K, the fixed premium ladder had rungs at 8, 10, 12 and 16 Mbps; the August 28, 2020 shot-optimized rollout put the average top 4K rung at 8 Mbps and the entry point above 1080p at 1.7 Mbps instead of 8, and Netflix's A/B tests showed rebuffers per hour down over 65% (Shot-Based Encodes for 4K).

On a November 13, 2025 snapshot AV1 carried about 30% of Netflix viewing, AV1 sessions used one-third less bandwidth than AVC and HEVC sessions, and Netflix reports 45% fewer buffering interruptions (AV1 at 30%, December 1, 2025); that compares session populations, not a controlled test. On the ladder from 235 kbps to 15 Mbps that the Medium post and other explainers describe: 235 kbps was the 2010 floor, 5,800 that ladder's 1080p ceiling, 16 Mbps the fixed 4K ceiling, and 15 Mbps is the help center's recommended connection speed for 4K, next to 3 Mbps for 720p and 5 for 1080p (Netflix Help Center). It is guidance for your ISP plan, not a rung.

Why a Wi-Fi dip softens the picture instead of stalling

The Medium post opens on a Wi-Fi dip that softened the picture for ten seconds without a stall. The mechanism is in a SIGCOMM 2014 paper by Te-Yuan Huang, Ramesh Johari and Nick McKeown of Stanford with Matthew Trunnell and Mark Watson of Netflix: pick the next chunk's bitrate from buffer occupancy alone rather than a throughput estimate (Buffer-Based Approach to Rate Adaptation). In Netflix's 2013 browser player the buffer was 240 seconds in 4-second chunks; until a 90-second reservoir filled the client always requested the minimum rate, normally 235 kb/s, from 90 to 216 seconds the rate rose linearly, above 216 it requested the maximum, and one second of buffer drains per second of playback (SIGCOMM 2014). When your Wi-Fi dips the buffer drains a little, the rate map answers with a lower rung, the next chunks are smaller, the buffer recovers, the rate climbs back. A ten-second dip against minutes of buffer is absorbed by requesting a smaller file, which is the picture going soft; a stall is the whole 240 seconds running dry, and the 90-second reservoir is only the point below which the client asks for nothing but the smallest file.

The paper names the cause: throughput variation "can be caused by many factors, such as WiFi interference", and off-peak rebuffers are dominated by random local events rather than congested networks (SIGCOMM 2014). The result, from 2013 A/B tests, was a 10 to 20% lower rebuffer rate than Netflix's then-default algorithm at a similar average video rate, and 20 to 28% for the BBA-1 variant during peak hours only; the paper says embedded devices have smaller buffers, and a footnote says the production algorithm "is now different" (SIGCOMM 2014). The 2021 AV1 post says the same in the present tense: when conditions cannot sustain the current quality, the player switches to a lower bitrate stream (AV1 on TVs, November 9, 2021).

Now the hinge. Netflix's July 2025 comparison table says on-demand players "pre-fetch a large buffer with dozens of segments", measured in minutes, while live players "keep a short buffer of just a handful of segments", measured in seconds (Part 1). Every graceful thing above depends on minutes of reserve. Live has seconds. A ten-second dip is smaller than a VOD buffer and bigger than a live one.

November 15, 2024: the night the request could not be the last step

Netflix drew the distinction itself in December 2025: Open Connect is "more of a distributed origin server" where VOD assets are pre-positioned "rather than being filled on demand", and live "differ[s] significantly from on-demand where we have significant time ahead-of-time to pre-position content" (Netflix Live Origin). The Part 1 table says live "draws viewers during an exact time" and needs "smoothing to avoid 'thundering herds' of requests", with segments two seconds long; the same post admits "we can (and did!) find ourselves in a situation where viewership exceeded our predictions and provisioned capacity" and reports "a 10x increase in traffic load due to stream restarts after viewing interruptions of as little as 30 seconds" (Part 1). That 10x is the failure mode of a short buffer under load: a stall becomes a restart, and a restart is a new request at the worst moment. There is no 2AM window; the fill is the request, and a fill window cannot help an event whose bytes do not exist at 2AM.

Kentik's curve shows where it bent. Embedded-cache traffic rose steeply just before 01:00 UTC on November 16 (8pm ET); at a certain point afterward the embedded-cache and private-peering curves both turned jagged while transit rose "to partially supply the content not being satisfied by caching or peering", and Madory declined to name a culprit (Kentik, November 21, 2024). Reuters, citing Downdetector, reported roughly six hours of trouble in the US with "more than 90,000 reports of problems with Netflix" at the peak (Reuters via Yahoo Finance); other snapshots ran from roughly 97,000 (The Hollywood Reporter) to more than 100,000 (Bloomberg, syndicated). None of those is a share of viewers.

Two operators gave competing accounts. John van Oppen, VP of Network at Ziply Fiber, posted on November 16 that Ziply saw almost 2.5 times its normal Netflix peak with "near zero reports of issues" and said Ziply augments peering at 40% utilization where many providers run links at 80% (van Oppen, LinkedIn); an anonymous operator in his comments claimed the opposite, that Netflix's peering clusters failed over at about 30% utilization (same post). Dan Rayburn's corrective of November 18 is the one to keep: Netflix used Open Connect exclusively with no third-party CDN, the fight was its ninth live event by his count, and "No one knows the percentage of overall users that had bad QoS" (Rayburn, LinkedIn). He later reported that "Netflix was using 1-second segments, which was surprising" and that seven ISPs he spoke with saw no capacity problems on their own links (Streaming Media Blog, December 23, 2024).

Netflix's own acknowledgments came by memo and on stage. CTO Elizabeth Stone wrote to employees that the team had handled the scale by "prioritizing stability of the stream for the majority of viewers" (TheWrap, citing Bloomberg) and did not want to dismiss "the poor experience of some members" (Front Office Sports, November 18, 2024). Ted Sarandos at the UBS conference on December 10, 2024: "We were stressing the limits of the internet itself that night" (The Hollywood Reporter). The Q4 2024 letter calls the fight the most-streamed sporting event ever and never mentions the problems (Q4 2024 letter). A class action filed November 18, 2024 in Florida state court called Netflix "woefully ill-prepared" and sought unspecified damages (Variety); the $50 million figure some outlets printed is not on the docket. The case, later captioned Scott v. Netflix, Inc., No. 8:25-cv-00775 (M.D. Fla.), ends with a notice of voluntary dismissal on April 9, 2025 and termination on April 10, with no settlement or class relief on the docket (CourtListener).

What Netflix says it changed, and what it has not shown yet

The earliest dated statement is from the Kansas City Star on December 5, 2024: Netflix was working with partner ISPs to increase interconnection capacity, some behaviors of its live systems are "impossible to replicate in a lab environment", and it was addressing the main pressure points before the NFL games (Kansas City Star). USA TODAY carried it on December 24 and added that ISP capacity was "taxed" (USA TODAY via Yahoo). Two days before the games Stone gave The Verge the only first-party statement that locates the failure: the AWS side held, while the connection points between the appliances and the last mile the ISPs give to devices did not. "All of that was overloaded during the fight." She added that Netflix had augmented its Open Connect servers, that several ISPs had added capacity where it overloaded, and that no lab can simulate 65 million people watching at once (The Verge, December 23, 2024).

Nothing in Netflix's engineering posts dates a specific system to that window. Part 1 lists the levers undated: capacity forecasts shared with ISP and cloud partners ahead of time, synthetic load tests at up to 100,000 stream starts per second, load shedding that favors live over pre-fetch, and monitoring at up to 38 million events per second (Part 1). The Live Origin post describes what the origin does instead of pre-positioning: a 2-second retry budget, only designated top-tier OCAs allowed to fill from the origin, an HTTP 503 with max-age=5s when low-priority traffic is shed so Open Connect caches the failure for five seconds, cacheable 404s for unpublished segments with expiry tied to publish time, and millisecond-grain nginx caching because one-second Cache-Control is coarse against 2-second segments (Netflix Live Origin). Since January 26, 2026 every live event is VBR rather than CBR, with Netflix reporting about 5% fewer rebuffers per hour and 15% fewer bytes, Netflix's own A/B figures, which nothing outside Netflix can check (VBR for Live, April 2, 2026). The one concrete pre-Christmas change anyone observed is Rayburn's: one-second chunks for the fight, two-second for the NFL games (Rayburn Podcast 118, transcript), an observation of manifests, not a Netflix statement.

The scoreboard since. On Christmas Day 2024 Variety saw Downdetector US reports at "a peak of about 600 as of 1:13 p.m. ET" (Variety) and Front Office Sports counted about 6,000 from half an hour before the first kickoff to halftime of the second game, against 530,000 before the fight's main event (Front Office Sports); Rayburn, logging the stream that day, saw 2-second chunks, CMAF/DASH with H.264 at 1080p, and wrote "I give Netflix an A on the stream." (Rayburn, December 25, 2024). But no concurrency figure was published: Netflix's release gives Nielsen averages of 24.3 million and 24.1 million and the word concurrent does not appear in it (About Netflix, December 26, 2024), and the NFL said only that nearly a third of Netflix's global concurrents were watching the first game (NFL Media). Kentik measured the fight at more than double the NFL games' traffic and asked "So, did Netflix resolve its delivery issues between mid-November and Christmas? Maybe." (Kentik, January 8, 2025). WWE Raw's January 6, 2025 debut ran 87.9% from embedded cache on 28% less traffic than the NFL games (Kentik), drew 4.9 million views, and produced no technical statement either way (About Netflix). Canelo vs Crawford on September 13, 2025 peaked at "over 24M concurrent streams", about 37% of the record (About Netflix, September 15, 2025), and the Netflix event releases I read since, including Paul vs Joshua and NFL Christmas 2025, report no concurrent-stream peak at all (About Netflix, December 31, 2025). The most recent synchronized-demand incident is press-relayed and was a pre-recorded premiere: TechTimes reported on August 27, 2026 that a GTA VI premiere drew "more than 3,000 problem reports at peak" on Downdetector, with no Netflix statement (TechTimes). The fixes are documented. Proof at 65 million is not.

What a one-person site can copy, with prices

A static site's request is the last step only if you make it so, and by default it is not. Cloudflare's CDN "does not cache HTML or JSON by default"; it caches by file extension, the default edge TTL for a 200 with no cache headers is 120 minutes, and any response carrying Set-Cookie, private, no-store or no-cache is never cached (Cloudflare default cache behavior). The free-plan reader who proxies a zone in front of an origin hosted somewhere else, and believes they are behind a CDN, is serving the HTML of every page view from that origin, even while the stylesheet and images behind it are cached. (If the site itself is hosted as Workers or Pages static assets there is no origin bill to protect, per the hosting row in the table below; the Cache Rule step is for the proxied case.) The fix is a Cache Rule marking HTML "Eligible for cache" with an Edge TTL, and you get 10 rules on Free, 25 on Pro, 50 on Business (Cache Rules). The Edge TTL has three modes and only one of them works with the header advice further down: the two "Use cache-control header if present" modes defer to your origin, and Cloudflare does not cache a response marked no-cache, no-store, private or max-age=0 (default cache behavior), which is what MDN's rule for the HTML sends. Pick "Ignore cache-control header and use this TTL", and leave Browser TTL on "Respect origin" so the visitor's browser still revalidates the page while the edge serves it (Cache Rule settings). With either other mode the header below reads BYPASS and you are back at the origin. The instrument is the cf-cache-status header: HIT, MISS, EXPIRED, DYNAMIC (not eligible) and BYPASS (eligible, but the origin response was not cacheable) (cache responses). And one clause rules out the option people reach for first: Cloudflare's Application Services terms, under the heading "Content Delivery Network (Free, Pro, or Business)", require non-Enterprise customers to use paid products such as Stream, Images or the Developer Platform for video and large files, and reserve the right to limit CDN access if you "serve video or a disproportionate percentage of pictures, audio files, or other large files" without them (Cloudflare terms). Pro and Business included.

The CDN prices, as read on September 11, 2026:

Provider	Free allowance	Then	Catch
Cloudflare Workers or Pages hosting	"Requests to static assets are free and unlimited", and storing them costs nothing (static assets billing)	n/a for static files	Only requests that run Worker code are billed; 25 MiB per file and 20,000 files per site on Free, so a video goes in R2, not in the site (Pages limits)
Bunny CDN, Standard	14-day trial	$0.01/GB Europe and North America, up to $0.06 Middle East and Africa (Bunny)	$1 monthly minimum; no request fees
CloudFront, pay as you go	1 TB out and 10 million requests a month (AWS)	$0.085/GB in AWS's example	Invalidations cost past 1,000 paths
Netlify, Free plan for new accounts	300 credits a month, hard limit (Netlify)	20 credits per GB, so 15 GB if spent on nothing else	Site not available past the limit; a successful production deploy also costs 15 credits, so 20 deploys in a month spend the whole allowance before a byte is served (how credits work); the credit plans apply to accounts created on or after September 4, 2025

The fuller host comparison is in What Hosting a New Business Site Actually Costs in 2026 and the cache-hit side in You're paying for a CDN. Your cache hit ratio says it's not working.. Video belongs on a host that bills per minute delivered rather than a CDN you hope will hold. Per 1,000 minutes, as read on September 11, 2026:

Host	Stored, per 1,000 minutes	Delivered, per 1,000 minutes	Catch
Cloudflare Stream	$5 a month, prepaid in $5 blocks, so $5 is also the smallest bill; the extra quality levels Stream generates are not charged as storage (Stream pricing)	$1, post-paid; 60 minutes watched is $0.06	Ingress and encoding free
Mux	$2.40 at 720p, $3.00 at 1080p, a month (Mux docs)	$0.80 at 720p, $1.00 at 1080p, after 100,000 free minutes a month	Basic input free; Premium about $0.038/min; the pay-as-you-go plan lists a "$20 monthly usage credit" (Mux pricing)
Bunny Stream	About $0.38 per rendition at 720p, my arithmetic (Bunny Stream pricing)	About $0.19 on Volume, about $0.38 on Standard, my arithmetic at 5 Mbit/s	Per GB, so bitrate sets the bill; $1 minimum
YouTube, unlisted	No fee	No fee	Ads may run; age-restricted videos redirect off your site (terms, embed help); unlisted is not private, anyone with the link can watch and share it and it surfaces if someone adds it to a public playlist (unlisted help)

Mux's free tier is the largest on the table, and its docs put it plainly: "The first 100,000 minutes delivered each month, regardless of quality or resolution, are free" (Mux docs). Bunny's row is my arithmetic from its per-GB prices, $0.01/GB stored and $0.005 or $0.010/GB delivered with every rendition billed (Bunny Stream pricing), at the approximate 5 Mbit/s for 720p in its adaptive bitrate doc (Bunny ABR doc): 1,000 minutes is 37.5 GB, and Bunny's own default encode is lower, so the delivery figure is an upper bound; storage is billed on every rendition Bunny produces, so the storage figure is one rung of a ladder, not the whole bill. YouTube's terms never say free; they are silent on any fee to upload or embed and grant YouTube the right to monetize your content with ads (YouTube terms). Whichever host you pick, search is separate: your video has 10,000 views and zero search impressions because the schema is missing.

The per-title equivalent for one person is an ffmpeg ladder, and I read the ffmpeg wiki through archived copies. CRF runs 0 to 51 with 23 as the default and a "subjectively sane range" of 17 to 28, and the general recommendation is CRF (ffmpeg H.264 guide, archived September 9, 2026):

ffmpeg -i input -c:v libx264 -preset slow -crf 22 -c:a copy output.mkv

The same page says plain CRF is not recommended for streaming and gives the capped form, which is the rung you want (ffmpeg H.264 guide, archived):

ffmpeg -i input -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M output.mp4

Three runs with three caps is a three-rung ladder, per-title encoding at the scale of one person; the guide notes that libx264 does not hold the cap strictly and reserves two-pass encoding for a target file size (same guide). Its two-pass form, for when a size has to be hit rather than approached, with NUL in place of /dev/null on Windows (same guide):

ffmpeg -y -i input -c:v libx264 -b:v 2600k -pass 1 -an -f null /dev/null && ffmpeg -i input -c:v libx264 -b:v 2600k -pass 2 -c:a aac -b:a 128k output.mp4

On time: the presets run ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, and the guide says veryslow needs 280% of medium's encoding time for only minimal improvement over slower, so slow is where one person should stop (same guide). The ladder is for a file you serve yourself, an mp4 behind Bunny CDN or in an R2 bucket, and it has a limit the Netflix ladder does not: three mp4 files are three choices a visitor makes once, not a player that steps down a rung when the Wi-Fi dips. The stepping down needs renditions a player can switch between, and Stream, Mux and Bunny Stream generate those from whatever you upload (Stream pricing); there you encode once and let the host build the rungs. Netflix's AV1 gain has a one-liner too, with SVT-AV1's CRF running 0 to 63 and defaulting to 35 (ffmpeg AV1 guide, archived September 11, 2026):

ffmpeg -i input.mp4 -c:a copy -c:v libsvtav1 -preset 8 -crf 35 svtav1_test.mp4

The image version is srcset and sizes, and MDN's reference example is the whole pattern: the browser takes the first true condition in sizes and loads the candidate that matches that width or the first larger one (MDN, responsive images):

<img srcset="elva-fairy-480w.jpg 480w, elva-fairy-800w.jpg 800w" sizes="(width <= 600px) 480px, 800px" src="elva-fairy-800w.jpg" alt="...">

AVIF, at 95.36% global browser support on September 11, 2026 (Can I Use), is your AV1, and in the sharp library it is one call, await sharp(input).avif({ effort: 2 }).toBuffer(), with defaults of quality 50 for AVIF and quality 80 for WebP (sharp output API).

Cache headers done right, and the trap that hides a deploy for a year

The header is the pre-positioning. RFC 8246, September 2017, defines Cache-Control: immutable as a promise that the origin will not update the representation during the freshness lifetime, says clients "SHOULD NOT issue a conditional request during the response's freshness lifetime (e.g., upon a reload)" unless the user force-reloads, and gives Cache-Control: max-age=31536000, immutable, one year, as its example (RFC 8246). MDN's best practice is the cache-busting pattern: a version or hash in the URL of every static resource, never modified in place, served with that one-year header, while the HTML that references them is served with no-cache (MDN, Cache-Control). MDN's two rules, verbatim:

# /assets/*
Cache-Control: max-age=31536000, immutable
# /index.html
Cache-Control: no-cache

Cloudflare's own example of the one-year header applies only to a folder of fingerprinted assets, its default being public, max-age=0, must-revalidate (static assets headers). It also documents immutable as "Browser facing, does not impact caching proxies", and notes that Always Online disables the RFC 5861 stale-serving directives, stale-while-revalidate and stale-if-error (Cloudflare, Cache-Control, RFC 5861). Those two directives are the closest a static site gets to Netflix caching a 503 for five seconds, degrade rather than fail: RFC 5861's own example, Cache-Control: max-age=600, stale-if-error=1200, lets a cache keep serving the last good copy for twenty minutes after the origin starts erroring, and Cloudflare honors both unless Always Online is on, and drops stale-while-revalidate if you also send s-maxage (Cloudflare, Cache-Control, RFC 5861). The vendor ties immutable to hashed filenames. So should you.

Here is the trap, told twice because I hit it twice. On August 31, 2026, on a client site I will not name, I built a new footer, deployed it, and verified the served stylesheet byte for byte at the origin; in a browser that had visited the site earlier that day the footer rendered as unstyled bullets. The site had a wildcard rule applying immutable with a one-year max-age to the whole stylesheet path, and the stylesheet was called site.css. RFC 8246 had done what it says: the browser never asked again. On September 3, 2026 I hit it on jwatte.com, where netlify.toml applied the same rule to every .js file and all 26 scripts had unversioned names; a corrected banner was live at the origin and stale in a browser that had loaded the page an hour earlier. Every server-side check passes in this failure. The CDN has the right bytes, an incognito window looks perfect, and the only people who see the old file are returning visitors, the population that matters; I wrote about that class of check in Green checks that cannot fail. The fix on the client site was an eight-character content hash in the filename, computed before page generation so the pages could embed it:

const hash8 = s => crypto.createHash('sha256').update(s).digest('hex').slice(0, 8);
const CSS_FILE = `site.${hash8(CSS_TEXT)}.css`;   // -> site.e0aacec1.css

On jwatte.com, where an idempotent injector writes the script tags, the fix was ?v= plus ten characters of the SHA-256 in the query string, with the injector updating a stale hash rather than adding a second tag; the other 25 files were still under the rule when I wrote this. Two things follow if you have already shipped the bad rule. Deleting the word immutable and keeping the year does not rescue visitors who already hold the file: immutable adds the reload case, and a fresh one-year copy is already used without asking on a normal visit (RFC 8246). And the header cannot be recalled, because a browser holding the file will not ask about it again; the new bytes reach it only through a new URL, learned from the HTML, which is why MDN's pair is two rules and the no-cache on the page itself is what makes recovery possible (MDN, Cache-Control). If the HTML was under the same wildcard, even that path is closed until the HTML expires. Then test that the hash moves when one byte changes and moves back when you revert. A hash that never changes is worse than no hash, because it looks solved.

Pre-warming, measuring at the client, and what does not translate

Warming the CDN at deploy time is the usual translation of the fill window, and the Medium post offers it, but the operation does not exist on the CDN you are likely using. Cloudflare's purge documentation lists purge by URL, everything, cache-tag, hostname and prefix, all on Free, at 800 URLs per second for single-file purge and five requests a minute for the rest, and contains no prefill, pre-warm or preload operation (purge cache). Cache Reserve admits an asset only after a request misses the edge and goes to origin, needs a freshness TTL of at least 10 hours, and costs $0.015 per GB-month plus $4.50 per million writes (Cache Reserve); as of today Cloudflare's own pages disagree on who can buy it, the Cache Reserve page asking only for a paid Cache Reserve subscription while the Smart Shield page puts it in a package that is not available to Free, Pro or Business (Smart Shield). Bunny answers in one sentence: it does not allow preloading files into cache (Bunny FAQ), and its Perma-Cache fills only on cache misses, so the first visitor still pays the origin fetch, at $0.01/GB per region for the storage, and while it is on "Wildcard purging and tag-based purging do not work", which matters on the day you deploy (Perma-Cache, storage pricing).

What you can do is smaller and real. Smart Tiered Cache is free on every Cloudflare plan and routes every edge miss through one upper-tier data center, which alone may fetch from origin (Tiered Cache). A Worker cannot push-fill the network either, since cache.put stays in the data center where it ran (Workers Cache API). So the drill, which does nothing for HTML until the Cache Rule above is in place: turn on Smart Tiered Cache, deploy, purge everything, request your top pages once yourself, then read cf-cache-status on a second request from somewhere else, where a HIT carrying an Age older than your own request means the fill came from the upper tier and not from your origin (cache responses). That one request is your fill window, and it comes after the first request, which is the whole difference from Open Connect. The drill is my derivation from the docs, not a documented feature.

Measure at the client, because a lab cannot see the returning visitor. Core Web Vitals thresholds are LCP within 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1, assessed at the 75th percentile of page loads split by mobile and desktop; web.dev says lab measurement is not a substitute for field measurement, and Lighthouse cannot measure INP at all because nobody interacts with the page, though Chrome DevTools can when you do (web.dev). The free field source is the Chrome UX Report, which counts users with usage-statistics reporting on, history sync and no sync passphrase, and includes an origin only if it is publicly discoverable and "sufficiently popular", a threshold of which Google says "An exact number is not disclosed." (CrUX methodology); a small site may have no row at all, and what there is comes as a 28-day rolling aggregate. The place to look is PageSpeed Insights, which shows the CrUX row for an origin and says so when it has insufficient data (PageSpeed Insights docs). The fallback is Cloudflare Web Analytics, free on up to ten non-proxied sites, with a Core Web Vitals section and no cookies, no localStorage and no fingerprinting, which answers the question of what leaves the visitor's machine (Web Analytics limits). My client-side method that avoids the PageSpeed quota is in Auditing Core Web Vitals: A Client-Side Approach Without the PSI Quota, and your LCP element is probably a lazy-loaded hero image.

What does not translate, so you stop trying. Netflix peers as AS2906 at exchanges and its embedded appliances peer with the host ISP as AS40027, and it adds a MED of 50 to private-interconnect routes and 100 to exchange routes before geolocation gets a say (Open Connect peering). A free appliance requires a public ASN, one or two 100G ports or two to six 10G ports in a LACP bundle, 350 to 700W, 1.2 Gbps of inbound fill every day and a Netflix traffic review (Open Connect requirements), on top of a program Netflix puts at $1B+ over 12 years (Part 1). Nobody will ship you a box for a public ASN, no commercial CDN has a fill window, and your one spike is the live event you cannot pre-position. For on-demand video the request is the last step, and Netflix has spent the fifteen years since Open Connect began in 2011 making sure of it (Open Connect Overview). What you can pre-position is everything else: cacheable HTML, hashed assets with a one-year header, an upper tier filled by your own first request, video on a host that meters minutes, and a field metric for the returning visitor. The Netflix half of the pattern is a separate read in Streaming Pipelines and Platform Engineering. If you are building the small-business site all of this sits under and want the whole map from domain to first customer, that is what I wrote The $97 Launch for.

Fact-check notes and sources

Fill window: 12 hours, 2AM to 2PM local, shiftable two hours, 1.2 Gbps and 6.5 TB per Storage appliance, 0.4 Gbps and 2.1 TB per Global, "During live events" as an out-of-cycle trigger: Netflix Open Connect partner article, Fill patterns, read September 11, 2026, openconnect.zendesk.com. The August 22, 2025 Deployment Guide PDF also had a Flash column (0.3 Gbps, 1.6 TB) that the live article has dropped; a 2016 copy said 10 to 12 hours from 2AM to noon.
Archived Fill patterns copies without the live-events line: Wayback snapshots of December 25, 2024 and November 18, 2025, web.archive.org and web.archive.org. The archive's index was intermittently offline during research, so the change is bounded only as after November 18, 2025 and by September 11, 2026.
"No, this is not possible" on widening the fill window: Open Connect partner FAQ, openconnect.zendesk.com.
Popularity as bytes streamed divided by size, smoothed over days, per region, file-level ranking at 50% of storage, hand-pinning, replication proportional to popularity, files locked in memory: Content Popularity for Open Connect, June 20, 2017, netflixtechblog.com.
Proactive caching as the stated difference from other CDNs, manifest from AWS, peer then tier then cache fill, window moving west: Netflix and Fill, August 11, 2016, netflixtechblog.com.
10 to 20% of titles served from memory: Serving 100 Gbps from an Open Connect Appliance, September 29, 2017, netflixtechblog.com.
Medium post headline, subtitle, dates, paywall, the second paragraph separating 260 million households from 65 million streams, and its 300 Tbps arithmetic: The Speedcraft Lab, Beyond Localhost, July 10, 2026, edited July 15, member-only story, medium.com. The subtitle is the one quotation used. The public preview ends mid-sentence; what the remainder covers rests on my own notes from a logged-in read, which I could not confirm again afterward. The terabit figure is 65 million times 5 Mbps; no Netflix source gives a per-stream bitrate for the fight.
260.28M paid memberships at end of 2023, "over 260 million households": Q4 2023 shareholder letter, January 23, 2024, s22.q4cdn.com. The households phrase is in the letter's prose; the table row is paid memberships. The same figures are in the SEC 8-K exhibit filed the same day.
301.63M at end of 2024, audience over 700M, no mention of fight-night technical problems: Q4 2024 shareholder letter, January 21, 2025, s22.q4cdn.com.
End of quarterly membership reporting, first letter without the row, 325M milestone: Q1 2024 letter, April 18, 2024; Q1 2025 letter, April 17, 2025; Q4 2025 letter, January 20, 2026. "Only milestone" is verified for the shareholder-letter series, not every press release.
65 million concurrent streams, 38 million in the US, 108 million AMA, no mention of buffering: About Netflix, November 19, 2024, about.netflix.com. Self-reported; AMA from TVision plus first-party data, not Nielsen. The Live Origin post repeats 65 million; The Human Infrastructure post of April 17, 2026 says 64 million.
65.2 million on JioHotstar for the March 5, 2026 semi-final, in an ICC release dated March 7, and 72.5 million for the March 8 final: ICC media release, icc-cricket.com; News9live citing the ICC, news9live.com. No ICC release for the final itself was located.
17,000 servers in 158 countries as a spokesperson figure: The Verge, November 17, 2021, byline Catie Keck, theverge.com.
18,000 servers, 6,000 locations, 175 countries: About Netflix, December 14, 2022, about.netflix.com. The July 2025 "18K+ / 6K+" captions are a restatement.
OCAs do only two things, store no client data, steering service in AWS, no localization percentage, Open Connect began in 2011: Open Connect Overview PDF, copyright 2016, 2019, 2026, openconnect.netflix.com.
Before play in AWS, after play in Open Connect, tens of terabits per second, close to 90% direct: Ken Florance, About Netflix, March 17, 2016, about.netflix.com. The 95% figure is from a June 20, 2018 APNIC post by Netflix's Nihit Tandon, blog.apnic.net, and likewise counts all direct connections.
Cloud migration complete in early January 2016: About Netflix, dated February 12, 2016 on that page, about.netflix.com; the original tech blog copy is dated February 11.
No charge to qualifying ISPs, over a thousand ISPs: openconnect.netflix.com. The phrase is unchanged in archived copies from May 2020, so it is boilerplate rather than a dated count.
OCAs stop serving if AWS connectivity is lost: Open Connect Deployment Guide PDF, last updated August 22, 2025, openconnect.netflix.com.
Storage appliance about 200 Gbps, 120 TB, 400W; Global about 80 Gbps, 60 TB; FreeBSD -CURRENT, NGINX, BIRD: openconnect.netflix.com/en/appliances/, page footer 2026. The May 2024 version listed a 360 TB HDD unit, and Wikipedia still carries the older generation.
200 Gb/s per server since 2020, 240 Gb/s software kTLS, about 380 Gb/s NIC kTLS, EPYC 7502P, 4x100GbE, 18 NVMe: Drew Gallatin, EuroBSDCon 2021 slides, papers.freebsd.org.
"Almost 800Gb/s" claim, 731 Gb/s measured, 375 Gb/s baseline: Gallatin, EuroBSDCon 2022 deck, people.freebsd.org. Read for the two figures only; the article quotes the measured one.
Kentik fight-night measurements, 3x, 69.6 / 23.9 / 3.3 / 3.0, embedded-cache and private-peering curves both jagged, transit rising, no culprit named: Doug Madory, November 21, 2024, kentik.com. The 01:00 UTC timestamp is the onset of the rise, not the peak; the source says Kentik customers using OTT Service Tracking, not ISP customers.
89.9% embedded cache for the NFL games, fight more than double the NFL traffic, "Maybe", WWE Raw at 87.9% on 28% less traffic: Madory, January 8, 2025, kentik.com. Bits per second across Kentik's customers, not a concurrency count.
Ziply Fiber account, 2.5x, near zero reports, 40% versus 80%: John van Oppen, LinkedIn, November 16, 2024, linkedin.com; his title per his profile is VP of Network. The contrary account in the comments is anonymous and unverified; presented as competing.
Ninth live event, Open Connect only, no third-party CDN, share of affected viewers unknown: Dan Rayburn, LinkedIn, November 18, 2024, linkedin.com; the post was corrected inline from eighth to ninth.
1-second segments, manifests not refreshing, seven ISPs with no capacity problems: Rayburn, Streaming Media Blog, December 23, 2024, streamingmediablog.com.
One-second to two-second chunks: Dan Rayburn Podcast episode 118, machine transcript, buzzsprout.com. An observation of manifests, not a Netflix statement.
Six hours, more than 90,000 Downdetector reports: Reuters via Yahoo Finance, November 16, 2024, finance.yahoo.com. Downdetector's own page would not open for me; all counts are press-relayed report volumes, not shares of viewers.
Other Downdetector snapshots: roughly 97,000 (The Hollywood Reporter); approximately 99,494 at 10:45pm ET (Front Office Sports, November 15, 2024); more than 100,000 and "We crashed the site" (Bloomberg, syndicated copy); nearly 85,000 (AP); 530,000 cumulative US (Front Office Sports, December 25, 2024).
Stone memo quotes: TheWrap, November 17, 2024, citing Bloomberg, thewrap.com; Front Office Sports, November 18, 2024, frontofficesports.com. Bloomberg's original was not opened; outlets date its report November 17 or 18, 2024.
Sarandos at UBS, December 10, 2024: The Hollywood Reporter. His control-room line about re-engineering the internet is executive framing and is not adopted here.
Class action filed November 18, 2024, "woefully ill-prepared", unspecified damages: Variety, November 20, 2024, variety.com. The $50 million figure printed by some outlets is not on the docket and is omitted.
Amended complaint November 21, 2024, removal March 28, 2025: Hillsborough County Clerk HOVER docket for 24-CA-009170, reachable by entering the case number at hover.hillsclerk.com. Both named plaintiffs appear on the state docket after the amended complaint; the case is cited by caption only.
Scott v. Netflix, Inc., 8:25-cv-00775 (M.D. Fla.), voluntary dismissal April 9, 2025, terminated April 10, no settlement on the docket: CourtListener, RECAP copy last updated May 4, 2025. The Order's text is not exposed, so with or without prejudice is unknown.
Netflix statement of December 5, 2024, "impossible to replicate in a lab environment": Kansas City Star, kansascity.com.
December 24, 2024 variant, ISP capacity "taxed": USA TODAY Sports via Yahoo, sports.yahoo.com. The same passage appeared in at least six outlets with slight wording changes; the article's sentence is that ISP capacity was taxed, and the word interconnection belongs to a separate quote about growing capacity.
Stone to The Verge, December 23, 2024: AWS held, the connection points between appliances and the ISPs' last mile were overloaded, Open Connect servers augmented, ISPs added capacity, no lab can simulate 65 million: theverge.com. "All of that was overloaded during the fight." is the one quotation used from the interview; the augmentation line is paraphrased.
Part 1: 18K+ / 6K+, $1B+ over 12 years, 2-second segments, the VOD versus live table, "we can (and did!)", 10x restarts, 100K starts per second, 38 million events per second, forecasts shared with ISPs, load shedding: Behind the Streams, Part 1, July 15, 2025, Fedorov, Pham, Ribeiro, Newton, Wei, netflixtechblog.com. The table is an image and its text was read from the image. The A/B percentages are Netflix's own.
Live Origin: pre-positioned versus filled on demand, 65 million, 2-second retry budget, designated OCAs, 503 with max-age=5s, cacheable 404s, millisecond caching: December 15, 2025, Liu, Lynch, Newton, netflixtechblog.com. Throughput figures are Netflix's own.
VBR for all live since January 26, 2026; 5% fewer rebuffers, 15% fewer bytes: April 2, 2026, netflixtechblog.com. Self-reported A/B results; nothing outside Netflix can check them.
64 million concurrent streams: The Human Infrastructure, April 17, 2026, netflixtechblog.com.
Christmas 2024, about 600 Downdetector reports at 1:13 p.m. ET: Variety, December 25, 2024, variety.com. Tabloids ran crash headlines the same day and The Athletic called it up-and-down.
Rayburn's Christmas Day log: 2-second chunks, CMAF/DASH, H.264 at 1080p, "I give Netflix an A on the stream.": Rayburn's live blog, December 25, 2024, streamingmediablog.com. The chunk length was corrected from 3 seconds to 2 on December 26; one observer's log, not a Netflix statement.
About 6,000 reports versus 530,000: Front Office Sports, December 25, 2024, frontofficesports.com.
24.3M and 24.1M Nielsen AMA, no concurrent figure: About Netflix, December 26, 2024, about.netflix.com. No peak concurrency for the games has ever been published; the Q4 2024 earnings call transcript also contains no such figure.
Nearly a third of global concurrents: NFL Media on X, December 25, 2024, x.com. Relative only; it cannot be converted to a number.
WWE Raw 4.9M Live+1 views, no quality statement: About Netflix, January 9, 2025, about.netflix.com. No Downdetector count for the Raw debut was found in any outlet; the first reported Raw glitches were on February 3, 2025, and The Verge said the speculation pointed at WWE's production feed, theverge.com.
Canelo vs Crawford over 24M concurrent, September 13, 2025: About Netflix, September 15, 2025, about.netflix.com; self-reported via VideoAmp and first-party data. Press complaints that night were about production and scheduling, not an outage, per Marca.
NFL Christmas 2025 release with no concurrent figure: about.netflix.com. The Paul vs Joshua release and the Q3 2025 through Q2 2026 letters were also searched and contain no concurrency peak.
GTA VI premiere, more than 3,000 Downdetector reports: TechTimes, August 27, 2026, techtimes.com. Press-relayed count; the causal analysis is the outlet's own; no Netflix statement; the premiere was pre-recorded, not live.
Ten-rung 2010 ladder, 4,640 kbps, 20%, 1,540 versus 1,750, 5% grid, one JND: Per-Title Encode Optimization, December 14, 2015, netflixtechblog.com. The ladder is an image and was read row by row. A secondary source calling it a seven or eight rung 2014 ladder is wrong.
Per-shot encoding, 17.1% by harmonic-mean VMAF, keyframes at shot boundaries: Dynamic Optimizer, March 5, 2018, netflixtechblog.com.
VMAF motivation, DMOS from 10 to 100 at about 35 dB PSNR: Toward a Practical Perceptual Video Quality Metric, June 2016, Li, Aaron, Katsavounidis, Moorthy, Manohara, netflixtechblog.com.
Fixed 4K rungs 8, 10, 12, 16 Mbps; average top rung 8 Mbps; 1.7 Mbps above 1080p; over 65% fewer rebuffers per hour: Optimized Shot-Based Encodes for 4K, August 28, 2020, netflixtechblog.com. The 8 Mbps and 1.7 Mbps figures are offline evaluations over 100 titles; the 65% is an A/B result and Netflix's own.
AV1 at 30% of viewing, one-third less bandwidth, 45% fewer interruptions: December 1, 2025, snapshot of November 13, 2025, netflixtechblog.com. A comparison of session populations, not a controlled test.
Player switches to a lower bitrate stream to reduce the chance of interruption: Bringing AV1 Streaming to Netflix Members' TVs, November 9, 2021, netflixtechblog.com.
3 / 5 / 15 Mbps recommended connection speeds: Netflix Help Center, read September 11, 2026, help.netflix.com. The June 2021 version said 25 Mbps for 4K; 15 is the current figure only.
Buffer-based ABR: 240-second buffer, 4-second chunks, 90-second reservoir at the 235 kb/s minimum, cushion to 216 seconds, 10 to 20% fewer rebuffers, 20 to 28% for BBA-1 in peak hours, WiFi interference, 2013 A/B tests, "is now different": Huang, Johari, McKeown, Trunnell, Watson, SIGCOMM 2014, author-hosted PDF, yuba.stanford.edu. Browser-player data from 2013; the paper itself says embedded devices have smaller buffers. The reading that a stall is the full buffer emptying rather than the reservoir is mine, from the paper's rate map.
Cloudflare does not cache HTML or JSON by default, 120-minute default TTL, Set-Cookie and no-store bypass: developers.cloudflare.com, last updated September 3, 2026.
10 / 25 / 50 / 300 Cache Rules: developers.cloudflare.com.
cf-cache-status definitions and the Age note under Tiered Cache: developers.cloudflare.com, last updated September 4, 2026.
Video and large files barred on Free, Pro and Business without paid services, "serve video or a disproportionate percentage of pictures, audio files, or other large files": Cloudflare Application Services terms, section headed Content Delivery Network (Free, Pro, or Business), cloudflare.com.
Static asset requests free and unlimited on Workers and Pages, storage free, Worker-code requests billed: developers.cloudflare.com. Narrowed to static-file requests; the table row is hosting on Workers or Pages, not a proxied zone.
Default public, max-age=0, must-revalidate and the fingerprinted-assets immutable example: developers.cloudflare.com.
Bunny CDN per-GB rates, $1 minimum, no request fees: bunny.net/pricing/cdn/.
CloudFront 1 TB always free, $0.085/GB example, $0.005 per invalidation path after 1,000: aws.amazon.com. The $0.085 rate is the first paid band for the US, Canada and Europe; AWS's own page is inconsistent on whether requests are free to 10 or 20 million.
Netlify 300 credits, 20 per GB, Site not available, new accounts from September 4, 2025: docs.netlify.com. The $9 and $20 prices are on netlify.com/pricing; $0.13/GB is a derivation, not a listed price; the account-date scope is from Netlify's credit-plan documentation.
Cloudflare Stream $5 per 1,000 minutes stored, $1 per 1,000 delivered, 60 minutes = $0.06: developers.cloudflare.com, last updated September 8, 2026.
Mux $0.0008/min delivered at 720p, "The first 100,000 minutes delivered each month, regardless of quality or resolution, are free", $0.0024/min/month storage, Premium input $0.0375/min: Mux pricing docs, mux.com. The marketing page says $0.0384, hence "about $0.038".
Bunny Stream per-GB prices and rendition billing: bunny.net/docs/stream-pricing, last modified August 24, 2026. All per-minute Bunny figures are my arithmetic; the storage figure is for one rendition and every rendition is billed.
5 and 8 Mbit/s illustrative bitrates: bunny.net, a table published as an image and read visually. Bunny's dashboard defaults, about 2,800 kbps at 720p and 5,000 at 1080p, are lower, so the per-minute delivery figure is an upper bound.
YouTube: no fee stated, right to monetize, embedding permitted: YouTube Terms of Service effective December 15, 2023, youtube.com. The word free appears there only inside royalty-free. Age-restricted videos redirect off third-party sites per support.google.com.
ffmpeg CRF 0 to 51, default 23, 17 to 28, the CRF and capped-bitrate commands, plain CRF not recommended for streaming, libx264 not holding the cap strictly, two-pass for a target size: ffmpeg wiki H.264 guide, last modified June 22, 2025, read through the Wayback copy of September 9, 2026, web.archive.org. The live wiki would not open for me. The "three caps make a ladder" step is my framing, not the wiki's; I did not run any of these commands for this post.
SVT-AV1 one-liner, CRF 0 to 63 default 35: ffmpeg wiki AV1 guide, last modified August 20, 2025, Wayback copy of September 11, 2026, web.archive.org.
srcset and sizes selection rule: MDN, developer.mozilla.org.
AVIF 95.36%: Can I Use, read September 11, 2026, caniuse.com.
immutable definition, SHOULD NOT revalidate on reload, one-year example: RFC 8246, September 2017, rfc-editor.org. The one-year consequence for unversioned filenames is a reading of section 2, not a vendor warning.
MDN assets rule, hash in every static URL, no-cache for the HTML: MDN Cache-Control, developer.mozilla.org. The two-rule block is quoted verbatim from the cache-busting section; MDN's stale-while-revalidate example is a generic illustration of that directive, not its recipe for HTML.
immutable browser-facing on Cloudflare, Always Online ignoring stale-while-revalidate and stale-if-error: developers.cloudflare.com. The two directives are defined in RFC 5861, rfc-editor.org.
The two immutable incidents and the hash snippet: my own, August 31, 2026 on a client site that is not named here, and September 3, 2026 on jwatte.com, described from my own notes. The hash8 snippet is the client-site fix as written; on jwatte.com the hash went into the query string of the script tag rather than the filename, because the tag injector has to stay idempotent.
No prefill in Cloudflare purge docs, 800 URLs per second, five requests per minute: developers.cloudflare.com, last updated August 14, 2026.
Cache Reserve prices and admission rules: developers.cloudflare.com, last updated August 25, 2026.
Smart Shield Advanced not available to Free, Pro, Business: developers.cloudflare.com, last updated June 16, 2026. The two Cloudflare pages conflict as of September 11, 2026 and the dashboard was not checked.
Smart Tiered Cache free on all plans: developers.cloudflare.com. The "one request fills the upper tier" drill is my derivation from the doc text.
Workers cache.put does not replicate outside the originating data center: Workers Cache API, developers.cloudflare.com, which also says cache.put is not compatible with tiered caching.
Bunny does not allow preloading into cache: bunny.net.
Perma-Cache fills only on misses, disables wildcard and tag purge: bunny.net, last modified January 14, 2026.
Bunny storage $0.01/GB per region, $1 minimum: bunny.net/pricing/storage/.
Core Web Vitals thresholds, 75th percentile, field over lab, Lighthouse cannot measure INP while DevTools can: web.dev.
CrUX user criteria, discoverability and popularity criteria, "An exact number is not disclosed", 28-day window: developer.chrome.com. The 28-day window and the Dashboard deprecation notice are on sibling CrUX pages.
Cloudflare Web Analytics, 10 non-proxied sites: developers.cloudflare.com.
AS2906 and AS40027, MED 50 on private interconnects and 100 on exchange routes, applied before geolocation: openconnect.netflix.com/en/peering/.
Public ASN, 1 to 2 x 100G or 2 to 6 x 10G ports in a LACP LAG, 350 to 700W, 1.2 Gbps daily fill, traffic evaluation: openconnect.zendesk.com. The 5 Gbps minimum-traffic figure that circulates is not on the current page.
Sources that would not open for me: the Wall Street Journal's December 23, 2024 story (its claim that viewership was nearly three times the forecast is known only from summaries), Bloomberg's original memo report, Downdetector's own pages, The Athletic's Christmas assessment, the Pragmatic Engineer podcast segment with Stone, and, on a second attempt, the member-only body of the Medium post beyond the preview. Nothing above relies on them beyond what is labeled.

This post is informational, not legal, financial, or security advice. Mentions of third parties are nominative fair use. No affiliation is implied.

Netflix's real record is 65 million streams, and that was the night it buffered. Here is what a one-person site can copy.