Fix "HTTP Error 429: Too Many Requests" in yt-dlp

What is being counted

Not bandwidth. Requests. And the requests that matter are the metadata ones, not the downloads: for every video, yt-dlp fetches a watch page, sometimes a player script, sometimes an API endpoint. A 200-video playlist makes several hundred of those before the first byte of video is transferred.

That is why --limit-rate alone never fixes a 429, and why people report being blocked "before it even started downloading". The burst that trips the limit happens during extraction. --sleep-requests is the flag that addresses it, and it is the one most often left out.

The counter is per IP address, which is why a shared connection can hand you a block you did nothing to earn.

What to do right now

1. Stop

The single most effective action, and the hardest one. An automatic retry loop is not waiting — it is continuing to send requests, and each one extends the block. Close the terminal.

2. Confirm the block, cheaply

After twenty minutes, one request tells you where you stand. Use a video you know is public, and do not download it:

Still 429? Wait longer. Do not test again more than once every ten minutes — a probe is a request like any other.

3. Come back paced

Each of these does a different job, and the combination is what works:

• --sleep-requests 2 — two seconds between metadata requests. The one that actually addresses the cause.
• --sleep-interval 5 --max-sleep-interval 15 — a random pause before each download. Random matters: an exact five-second gap between every request is itself a machine signature.
• --limit-rate 2M — caps throughput. Secondary for 429s specifically, but it keeps a long job from looking like a scrape.
• -i — carry on past individual failures, so one blocked video does not end a six-hour run.

4. Make the job resumable

If you are archiving a channel, assume you will be interrupted. An archive file turns a restarted job into a continuation rather than a repeat:

Every completed video is recorded, and a later run skips it without making a request. This is also the difference between a nightly cron job that stays under the limit and one that re-extracts the whole channel every night — the playlist guide covers the full pattern.

5. Split large jobs

Rather than one command against 900 videos, take them in slices with a gap in between:

If it still fails

• 429 on the very first request, from a clean machine. Shared IP. University, office, mobile network or a cloud host — thousands of other requests came from that address before yours. Nothing local fixes it; try a different network.
• 429 turns into a bot check. That is escalation, not a different problem. The bot check page applies, but wait out the rate limit first — solving the second while still inside the first proves nothing.
• 429 alternating with 403. Also throttling. The server is refusing in whichever way is cheapest at that moment; treat both with the pacing flags above and see the 403 page if it persists alone.
• It only happens on a server or VPS. Datacentre ranges get much lower thresholds. This is by design and there is no flag for it.

Staying out of it

The pacing flags belong in your config file, not in the one command you remember to type them into. Two seconds between requests costs a playlist a few minutes; a 429 costs it a day.