A hobby podcaster recorded a weekly show about restoring vintage bicycles. He had no budget for podcast hosting, so he did what many beginners do: he uploaded each episode's audio file to the free website plan he already had, wrote the feed by hand, and submitted its address to the directories. The audience was a few hundred people. Everything worked, and he got into the habit of thinking of hosting as a solved problem.
One Thursday a much larger show mentioned his latest episode, with a recommendation and a link. Within a day, thousands of people tried to download it. By the evening his feed was returning errors, and the next morning the whole account was suspended. This is a fictional composite, but the arithmetic behind it is real, and so is the way he recovered.
The case has two halves: why the free plan failed so fast, and why the rescue was possible at all.
How the show was set up
A podcast is, mechanically, an RSS feed: an XML file listing episodes, each with a title, a date and a URL for an audio file. Listening apps fetch the feed on a schedule, notice new items, and download the audio from the URL in each item. There is no special podcast protocol beyond that. Anyone who can serve an XML file and some MP3s can run a show.
He had both on one site. The feed lived at https://example.com/feed.xml, the audio at https://example.com/audio/ep42.mp3, and the free plan served them as ordinary static files. The plan included a modest monthly bandwidth allowance, which he had never looked at because he had never come near it.
The arithmetic of a spike
Audio is heavy compared with web pages. A forty-minute episode at a typical spoken-word bitrate of 64 kbit/s comes to roughly 19 MB; at 128 kbit/s it is nearer 38 MB. Say his files were around 30 MB each (an example figure). A hundred downloads a week costs about 3 GB of transfer, which almost any plan will carry without complaint.
Now apply the spike. If five thousand people fetch that one episode in a day, the transfer is about 150 GB. Many free or entry-level plans allow only a few tens of gigabytes per month, some far less. At that rate the monthly allowance vanished in a few hours.
| Scenario (illustrative) | Downloads | Episode size | Transfer |
|---|---|---|---|
| Normal week | 150 | 30 MB | about 4.5 GB |
| Mentioned by a bigger show, first day | 5,000 | 30 MB | about 150 GB |
| Same, plus back-catalogue downloads | 8,000 | 30 MB | about 240 GB |
Podcast apps add to the load in a way that surprises newcomers. Many download new episodes automatically in the background, so a mention is not the only source of traffic: every subscriber with auto-download enabled fetches the file regardless of listening. Apps also poll the feed itself repeatedly, and a feed that returns an error gets retried.
What went wrong, in order
The failure unfolded in stages, and each stage made the next one worse.
- The mention went out in the morning. Downloads climbed steadily through the day.
- By mid-afternoon the plan's monthly bandwidth was spent. The host suspended the account, as its terms allowed.
- Requests for the audio started returning an error page, which the apps tried to save as if it were an MP3 and then reported as a failed download.
- The feed itself, on the same site, also failed. Apps that could no longer read it showed the show as broken or empty.
- Directories that revalidate feeds saw the errors. A few flagged the show as unreachable.
- People who had arrived curious, with no history of the show, took the error as the show's quality and drifted away. Some existing subscribers removed it.
The podcaster's first move was to email the host and ask for a bandwidth increase. The answer, reasonably, was that the free plan could not be extended and that he would need to upgrade a paid tier. By the time he read it, the burst was already over, and the damage was done.
The rescue: moving without losing subscribers
The hopeful part of the story is that the audience did not need to do anything. Subscribers had not subscribed to a file. They had subscribed to a feed address on his own domain, and he controlled that domain. That one choice, made months earlier almost by accident, turned a catastrophe into an afternoon of work.
He chose a podcast host that charges a flat monthly price with generous bandwidth and episode statistics. The migration followed the usual order:
- Upload the back catalogue to the new host, which generates a new feed.
- Check the new feed in two or three listening apps and in a feed validator, looking at episode titles, dates, durations and artwork.
- Make the old address redirect to the new feed with a permanent redirect. The redirect generator produces the right rules for most servers.
- Keep the old audio URLs redirecting to the matching files at the new host, so old episodes still play from cached feeds.
- Where the new host supports it, mark the feed as moved using the standard feed-redirect tag, so that apps update their stored address.
The permanent redirect in a typical setup looks like this on Apache:
Redirect 301 /feed.xml https://feeds.example.net/bikeshow/rss
RedirectMatch 301 ^/audio/(.*)$ https://media.example.net/bikeshow/$1Because the free plan was suspended, the redirects could only take effect after he moved the domain itself to hosting that was still running, which cost him a day. Had the feed address been on a subdomain such as a free provider's address, he would have lost every subscriber, since nobody could redirect it for him.
Why owning the feed address matters
This is the single most valuable habit in podcasting, and it costs nothing. Whatever host you choose, publish the feed under a domain you own and point that address at the host's feed. Treat the host as replaceable. Directories and apps then store your address, and you can swap the engine under it whenever you like.