Hosting cost glossary
Bill Variance: how to measure hosting cost predictability.
By Divyam Dhadwal · Last updated June 2026
- What it is: Bill Variance measures how much your hosting bill swings between a quiet month and a busy one.
- The formula: (busy-month bill − quiet-month bill) ÷ quiet-month bill. A score of 0 is fully flat; the higher the number, the more the bill moves with traffic.
- The rule: Match the variance to whether you can absorb a surprise. Predictability is only worth paying for if an unexpected bill would actually hurt.
Bill Variance is a simple measure of how much your hosting bill swings between a quiet month and a busy one. A platform with a Bill Variance of 0 charges you the same whether traffic doubles or flatlines. A platform with high Bill Variance can hand you a bill several times larger the month something takes off.
It answers a question pricing pages never do. Pricing pages tell you how cheap a platform looks on a calm month. Bill Variance tells you how predictable it stays on a bad one. Those are different questions, and the second is usually the one that wrecks a budget. We built Bill Variance at SelfHost to put a number on that second question.
Why hosting bills are so unpredictable
Most developers price a platform on its quiet month. You deploy, traffic is light, the bill is small, and that number becomes the one in your head. Then something changes: a launch, a feature on Hacker News, a seasonal spike, a runaway background job. The bill for that month looks nothing like the one you budgeted for.
That gap is not a billing error. It is how usage-based pricing is designed to work. The bill follows the traffic, and the costs that move fastest are the ones least visible up front:
- →Metered compute and autoscaling. You are charged for what you consume, so a 4x traffic month is a 4x compute month.
- →Egress and bandwidth. Often billed per GB, often the single line that turns a $30 bill into a $300 one, and almost never the number on the homepage.
- →Per-function or per-request pricing. Cheap per unit, unbounded in total.
- →Per-seat fees. Your bill grows when your team does, not when your app does.
None of these are inherently bad. The problem is that they are invisible until the month they are not, and by then the invoice has already arrived. Bill Variance is a way to see that risk before you commit, not after.
The Bill Variance formula
Bill Variance = (busy-month bill − quiet-month bill) ÷ quiet-month bill
In plain terms: take what the same setup costs in a heavy month, subtract what it costs in a light month, and divide by the light month. The result is how much your bill can swing, expressed as a multiple of your baseline.
- →A result of 0 means the busy month and the quiet month cost the same. Fully flat.
- →A result of 1.0 means a busy month costs twice as much as a quiet one.
- →A result of 2.6 means a busy month costs roughly three and a half times the quiet month.
The point is not that a high number is automatically bad (more on that below). The point is that the number exists at all, and that most teams never calculate it until the bill forces them to.
The four Bill Variance bands
To make platforms comparable, Bill Variance sorts into four bands:
| Bill Variance | Band | What it means |
|---|---|---|
| 0 to 0.25 | Very predictable | The bill barely moves with traffic. You can budget it to the dollar. |
| 0.25 to 1.0 | Moderate variance | A busy month costs noticeably more, but within a range you can plan for. |
| 1.0 to 2.0 | High variance | A busy month can double or triple the bill. Budget for the ceiling, not the floor. |
| 2.0 and up | Very high variance | A busy month can multiply the bill several times over. Hard to forecast. |
The labels are deliberately neutral. A "very high variance" platform is not a worse platform, it is a less predictable one, and whether that matters depends entirely on your situation.
A worked example: a spike month vs a quiet month
Say you run a small web service, a background worker, and a companion database. (Illustrative figures, to show the method.)
In a quiet month, light traffic, the setup costs $25.
Then you get featured. Traffic runs roughly 4x for three weeks. On a usage-based platform, the compute and bandwidth scale with it, and the busy-month bill comes in at $90.
Bill Variance = ($90 − $25) ÷ $25 = 2.6 → Very high variance.
Now run the same setup on a flat, per-service platform. Each service is billed at a fixed rate whether it serves ten requests or ten million, so both months bill the same, $25.
Bill Variance = ($25 − $25) ÷ $25 = 0 → Very predictable.
Same app, same traffic, same spike. The only thing that changed is whether the platform pricing model passed the spike on to you.
Bill Variance by platform: a cloud hosting cost comparison
The table below scores common app-hosting platforms by their pricing model, not by a single headline price. (Scores are illustrative, based on each platform published pricing structure, not on measured invoices. Run the formula on your own quiet and busy bills for an exact figure.)
| Platform | Pricing model | Typical variance | Band |
|---|---|---|---|
| SelfHost | Flat per-service rate, billed by the hour | ~0 | Very predictable |
| Render | Flat instance pricing | Low | Very predictable |
| Heroku | Fixed dyno pricing | Low | Very predictable |
| DigitalOcean App Platform | Fixed container pricing | Low | Very predictable |
| Vercel | Usage-based functions and bandwidth | Moderate to high | Moderate variance |
| Fly.io | Usage-based machines and bandwidth | High to very high | High variance |
| Northflank | Usage-based compute and add-ons | High to very high | High variance |
| Railway | Usage-based, billed per resource consumed | ~2.6 | Very high variance |
The split is not about price level, it is about pricing shape. Flat-rate platforms cluster near 0 because the bill is decoupled from traffic. Usage-based platforms sit higher because the bill is, by design, tied to it.
Related: Railway vs Render, a head-to-head on two usage-based platforms.
When high variance is actually the right choice
This is the part most comparisons skip, and it is the part that matters most. High Bill Variance is not a flaw. It is a trade-off, and sometimes it is the right one.
Usage-based pricing wins when:
- →Your app is idle most of the time. A hobby project, an internal tool, a side project that sees real traffic a few days a month. Scale-to-zero billing means you pay almost nothing when nobody is using it. A flat rate would charge you for hours you do not need.
- →Your traffic is genuinely spiky and you would rather not pay for headroom. If you only need capacity occasionally, paying per-use can be cheaper overall than reserving a fixed instance year-round.
- →You are early and small. At low volume, usage-based often costs less in absolute dollars than the smallest flat plan.
The honest rule is not "low variance good, high variance bad." It is: match the variance to whether you can absorb a surprise. If a 3x bill one month would be a non-event, high variance can save you money. If a 3x bill would be a problem you have to explain to someone, predictability is worth paying for. Bill Variance just makes that trade-off visible so you can choose it on purpose instead of discovering it on an invoice.
How to lower your Bill Variance
If predictability is what you are after, the lever is the pricing model, not the platform marketing. To keep Bill Variance low, look for:
- →Flat, per-resource pricing that does not move with traffic.
- →No metered egress (or egress that is included), since bandwidth is the line that surprises people most.
- →No per-seat fees, so your bill tracks your app, not your headcount.
SelfHost is built around this. App services run on a flat per-service rate of $0.021/hr (₹2/hr) per service, billed by the hour, so a quiet month and a busy month cost the same. That is a Bill Variance of effectively 0, by design, not by luck.
Bill Variance for databases
The same lens applies to your data tier, where the surprises are often worse. Managed database services frequently add scaling penalties, storage tiers, and egress charges that move the bill independently of how your app is doing. SelfHost managed PostgreSQL starts at $5/mo and runs on the same AWS instances as RDS for roughly half the cost, with no scaling penalties and no surprise egress invoices, so the database does not become the volatile line in your bill.