P.S. If you want more serverless and media-pipeline cost breakdowns like this one delivered to your inbox every week, join builders getting them free: https://wuki.beehiiv.com
Every video pipeline has a line item nobody wants to talk about: the encodes that never finished.
Not the slow ones. Not the expensive ones. The ones that died at 97% because a source file was corrupt, a codec flag was wrong, or the GPU instance got preempted mid-transcode. You delete the output, fix the input, and re-run it. And then you look at the bill — and the failed run is on it.
I ran my own video processing pipeline for a year, and failed encodes quietly cost me more than any single success. Here's what I learned about how video billing actually works, where the waste hides, and why the industry's default pricing model is backwards.
The four taxes on every video encode
1. You pay for failures (the big one)
Most hosted encoding services and cloud transcoding tools bill you by wall-clock compute time — the seconds your job held a worker, regardless of outcome. A 40-minute 4K transcode that crashes at minute 38 bills you for 40 minutes of GPU time. You output nothing, you pay full price.
It doesn't sound bad per-job. But failures cluster. One bad batch of source files — a camera that recorded with a broken timestamp, a batch of renders with a zero-byte tail — can burn through a week's encoding budget in an afternoon. I once had 14 of 20 jobs fail because a metadata field changed in a vendor export. Fourteen full-price bills for zero deliverables.
2. You pay for idle workers
When you self-host FFmpeg, your cost isn't the seconds FFmpeg runs — it's the seconds your server exists. Provision a box for your nightly batch and it sits idle 20 hours a day, still being billed. Autoscaling helps, but cold starts mean you keep a warm instance around "just in case," and "just in case" is a monthly line item.
3. You pay for spikes twice
Your median workload is 10 encodes a day. Your spike is 400 when a launch video goes viral. If you sized for the spike, you overpay 95% of the time. If you sized for the median, the spike queues for hours and your launch video ships late. Either way, you ate a cost that had nothing to do with the actual work done.
4. You pay minimums and round-ups
Per-second billing sounds precise until you read the fine print: minimum billable units, rounding up to the nearest minute, "burst" multipliers. Thirty 4-second clip renders shouldn't bill like thirty 60-second jobs — but they frequently do.
What I changed: bill on outcomes, not attempts
The fix that actually moved my numbers was switching my billing mental model from attempt time to successful output. Here's the key insight: charging for failed work is a tax on your own users' bugs, and it punishes the exact people you want to keep — the ones hammering your API with real workloads.
When I built my own encoding service (ffmpego.com — a serverless FFmpeg API I run as a side project), I made failed encodes free. The meter only runs on jobs that finish successfully. If your input is corrupt, your flags are wrong, or the job dies at 99%, you pay nothing. The economics work because the IDs that actually complete represent real work — and successful jobs are the ones users happily pay for.
Pricing by compute-second on success only also removed every other tax above:
- No idle workers — the platform scales to zero between requests; your cost is literally zero when nothing is running
- No spike premium — 400 jobs in a minute costs exactly 400 jobs' worth of compute, no warm-box overhead
- No minimums — a 4-second clip bill is 4 seconds × $0.0036, not a rounded-up minute
- Hard monthly caps — a spending ceiling you set, so a runaway loop can't silently empty your account at 3am
Why this matters more than the per-second rate
Frameworks and pricing tools obsess over the per-minute rate, and honestly, most of them are within a rounding error of each other. The real spread in your bill comes from what you're charged for that never should have been charged: failures, idle time, spike buffers, and rounding.
When I tracked my pipeline costs over a year, the "pure compute" part was about 60% of what I actually paid. The other 40% was taxes — and almost all of it was avoidable once the billing model aligned with outcomes.
Try the exercise yourself
Pull last month's encoding bill. Separate it into:
- Jobs that produced the file you wanted
- Jobs that failed, retried, or sat in a queue
- Idle/provisioned time you paid for but didn't use
If line 2 or 3 is anything but zero, your pricing model is working against you. You don't need cheaper per-second rates — you need to stop paying for work that never happened.
What does your last encoding bill look like — what percentage went to work you didn't actually get? I'd love to compare notes in the comments.
Top comments (0)