A fitness instructor sold a video course through her website and uploaded the videos directly to her hosting account. The first month, forty students watched a few hours each, and everything was fine.
In the third month, the host contacted her about excessive bandwidth and disk I/O, and threatened a suspension. Video files are large, and streaming them from a shared plan eats resources quickly.
She moved the videos to a streaming service built for the task and embedded them on the site, and her hosting went back to being quiet. The people in this story are invented, and the numbers are examples, but the pattern is one that support desks see every year: a business that works, on hosting that was never meant for what it became.
How the course was built
She taught classes in person for years and sold the first online course after a winter of lockdown-era requests. Twelve sessions of 30 to 45 minutes each, filmed on a good phone in her studio, edited on a laptop and exported at full HD. The files came out at around 1 to 1.5 GB apiece, which she did not think about, because the hosting plan advertised a generous disk allowance and the upload went through.
The site itself was a WordPress install with a membership plugin. Students paid, received a login, and saw a page for each session with the video file embedded using the browser's own player. It looked tidy and worked on phones. For the first month, with forty students dipping in and out, nothing went wrong.
What she had not realised was that she was running a video delivery service on a plan sized for a brochure site.
What happened in month three
By month three the course had been mentioned in a local newsletter, and student numbers had roughly doubled. They were also watching more: people who join a fitness course in January tend to do several sessions a week. The host's automated systems noticed first.
The email arrived on a Tuesday morning. It said the account had used a very large amount of bandwidth over the past weeks and was repeatedly hitting limits on disk reads and writes. Performance of other customers on the same server had been affected. If usage did not fall, the account would be suspended. They suggested a more expensive plan.
The students had noticed already. Videos stalled on the first minute, then played in bursts. The home page, which had nothing to do with video, took several seconds to load at the busy times of 6 am and 7 pm. She had assumed it was the students' broadband.
Why video is different
A typical web page weighs a couple of megabytes. A single 40-minute session at full HD is roughly a thousand times that. If the stream runs at about 5 megabits a second, forty minutes comes to around 1.5 GB. Watch it twice and you have served 3 GB to one person. Forty people doing four sessions each is hundreds of gigabytes in a month.
The page weight tool makes the comparison vivid. Paste in an ordinary page and then paste in one with a heavy video and watch the number change.
On shared hosting the problem is not only the data transferred. A web server serving large files reads them from disk, and when many people watch different parts of different files at once the disk is asked for many scattered reads. That is the "disk I/O" the host complained about. A shared server has a finite amount of it, and every customer on the machine feels the lack. Hosts therefore set limits, usually written in the terms as fair use, even when a plan is called unlimited.
Streaming services solve a different problem from file storage. They take your upload and produce several versions at different qualities. The player picks one that suits the viewer's connection and switches mid-play if the connection changes. The files are spread across servers close to the viewers. A plain MP4 on a web server does none of this.
The wrong turns
Her first move was to compress the videos. She re-exported them at a lower bitrate, which cut the size by a third and made them look noticeably worse, and the host's warning came again a fortnight later. The second move was to take up the host's suggestion of a bigger plan. It cost more than twice as much and had the same rules about heavy file delivery, just with a higher ceiling. A friend with a similar setup told her he had moved up twice already.
A third idea, to put the videos on a free public video site and link to them, would have worked technically. But it would have meant paying students watching alongside advertising, with recommendations to other people's classes next to hers, and anyone with the link could have shared it. She wanted the content behind the paywall.
It is worth saying what the host got right. The warning came before the suspension, it named the actual cause, and it offered a way forward, even if not the best one. Not every host does that. Some just throttle the account or take the site offline during the busiest hour, and the owner finds out from a student. Reading resource notices as a signal about your design, rather than as a sales pitch, saved her a good deal of money.
What she moved to
She chose a video hosting service intended for businesses that sell courses. Videos are uploaded once, processed into several qualities, and played through an embed code on the site. The service lets her restrict playback to her own domain, so that the links do not work if pasted elsewhere, and it charges by stored hours and by usage rather than by a hosting plan.
The rest of the work was an evening. She uploaded the twelve sessions, pasted the embed code into each lesson page in place of the old file, and tested a lesson as a paying student from a phone on mobile data. Then she deleted the old MP4s from her hosting account, which also freed several gigabytes and made her backups smaller.
Her hosting plan stayed as it was, her original cheap one. The membership plugin and the lesson pages were all that remained on it, and they are light.
What changed and what it cost
| Videos on hosting | Videos on a streaming service | |
|---|---|---|
| Playback quality | One fixed quality, stalls on slow links | Adapts to the viewer's connection |
| Load on hosting | High, grows with students | Negligible |
| Hosting plan needed | Bigger and bigger | The cheap one |
| Extra monthly cost | Plan upgrades | Per-usage fee, modest at this size |
| Control over who can watch | Direct file links can leak | Domain-restricted embeds |
Her total monthly cost went up slightly, from the old plan to the old plan plus the video service. It was a fraction of what the bigger hosting plan would have cost. More importantly, the cost now scaled with what she sold rather than leaping in steps.
Try it on your own site
Open a lesson page, open your browser's developer tools, switch to the Network tab and reload. Sort by size. If a single file of tens or hundreds of megabytes sits at the top, and it comes from your own domain, you are serving it from your hosting. From a terminal:
curl -sI https://example.com/videos/session-01.mp4 | grep -iE "content-length|content-type|accept-ranges"
du -sh ~/public_html/wp-content/uploads/* | sort -h | tailIn the hosting control panel, look for the bandwidth graph and any notices about resource limits. The troubleshooting guide explains how to tell a slow server from a slow connection.
Things people ask
Is it ever fine to host video on my own plan?
For a short clip on a page with modest traffic, yes. For anything you sell, or anything long, use a service built for streaming.
What about a VPS or dedicated server?
It removes the shared limits, but you still pay for the transfer and still lack adaptive streaming unless you set it up. It is a larger job than it looks.
Does the embed slow my pages down?
The player script adds some weight. Loading it only when the visitor presses play is a common way to keep pages quick.
Can students still download the videos?
Determined people can capture anything they can watch. Domain restrictions and private links stop casual sharing, which is usually what matters.
Afterwards
Hosting limits are written for the usual website, and video is not the usual website. Before selling something heavy, work out roughly how many gigabytes each customer will pull, multiply by the number of customers, and compare the answer with the plan. If the answer is a surprise, the files belong on a service that does the job.