Three VPS providers can quote the same server at the same headline rate and still send you three very different invoices. The difference is rarely the hardware. It is the meter: what is the smallest unit of time you can be charged for, and when does the clock actually stop?
Billing granularity became a spec people compare — the same way they compare NVMe or vCPU counts — when DigitalOcean moved Droplets to per-second billing on January 1, 2026, pitching it at ephemeral workloads: CI/CD pipelines, automated testing, autoscaled applications, and event-driven batch jobs. Good. It should be.
Our own KVM VPS are billed this way — quoted per hour, metered in whole hours, capped at 720 hours a month — so we have a position here. But the math below is vendor-neutral and checkable with a calculator. Bring one.
The three VPS billing models, defined
| Model | Meter granularity | Clock stops when | Typical pitch |
|---|---|---|---|
| Per-second | 1 second | Resource is destroyed | Ephemeral: CI, testing, autoscaling |
| Hourly | 1 hour — but rounding varies | Usually deletion, not power-off | Pay as you go |
| Monthly | Billing cycle | End of term | Predictable production spend |
Per-second billing
The meter runs in one-second increments from creation to destruction. A 4-minute job costs 240 seconds of compute, not an hour. DigitalOcean's stated rationale for the January 2026 switch was exactly this class of workload: short-lived machines that exist for minutes, then vanish. If your infrastructure is created and destroyed by scripts rather than humans, this is the model that matches how you actually consume compute.
Hourly billing
Here is where the label stops being enough information. "Hourly" describes the price quote, not necessarily the meter. Two sub-species exist:
- Hourly, rounded up. Hetzner Cloud is the documented example: partial hours are rounded up to full hours, and per their billing docs, a server that exists on your account is invoiced whether it is running or powered off — only deletion stops the charge. The saving grace is a monthly cap: hourly charges never exceed the server's monthly price.
- Hourly, rounded up, capped monthly. Our model: the price is quoted per hour, a started hour is billed as a full hour, and hourly usage is capped at 720 hours × the hourly rate per month — so a pay-as-you-go server never bills more than 720 hours in a month, and a box you forget about converges on that cap (within a few cents of the monthly price) rather than past it. The rounding is the trade: sub-hour jobs pay for the whole hour, which is an argument for packing short jobs into one machine that stays up for the hour.
Same word, materially different invoices. We will quantify that gap in a moment.
Monthly billing
Fixed price, fixed cycle, no meter to think about. You pay for the calendar month whether the box works hard or idles. That sounds wasteful until you notice that most production infrastructure runs 24/7 anyway, at which point monthly is usually the cheapest option on offer — providers discount it precisely because your commitment is predictable for them too.
The rounding trap, with numbers
Take a concrete pay-as-you-go scenario: a CI pipeline that spins up a fresh VPS per job, runs the test suite, and destroys the machine. 100 jobs a day, 4 minutes each.
Actual compute consumed: 100 × 4 minutes = 400 minutes = 6.7 compute-hours.
- Per-second (or per-second-metered hourly): you are billed for roughly 6.7 hours.
- Hourly, rounded up: each 4-minute job rounds to a full hour. 100 jobs = 100 billed hours. That is a 15× multiplier on identical workloads.
One detail worth pinning down: does the meter round up total usage, or bill every calendar hour the server touches? Hetzner's docs commit to the former — a server that exists "just for a few minutes" bills as one whole hour — but many billing pages never define it. Under calendar-hour metering, a job created at 14:58 and deleted at 15:03 could show up as two billed hours: five minutes of compute, two hours on the invoice. If the docs are silent, ask.
At small rates the absolute numbers look harmless: at €0.0056/hr, 100 rounded-up hours is €0.56/day versus €0.04 on a per-second meter. Nobody rage-quits over 52 cents. But scale the shape up 10×, run a build farm instead of one pipeline, or let an autoscaler churn machines every few minutes, and the same 15× multiplier applies to real money. The multiplier is the point, not the cents.
The hourly vs monthly break-even nobody does
The other direction matters too: at what utilization does monthly beat hourly?
Take our entry shape as the worked example: €0.0056/hr hourly, or €4/mo monthly. A nominal month is 720 hours.
- Full month at hourly rate: €0.0056 × 720 = €4.03
- Monthly plan: €4.00
- Break-even: €4.00 ÷ €0.0056 ≈ 714 hours, about 99% utilization
Below 714 hours a month, pay-as-you-go wins. Above it, monthly wins — by under 1% at full utilization. The hourly premium is the price of being able to leave; run the same ratio (hourly rate × 720 ÷ monthly price) on any provider you are comparing before you commit.
Two footnotes that change the answer:
- Monthly caps make hourly safer than the raw math suggests. Hetzner caps hourly charges at the monthly price; we cap at 720 hours a month, so even in a 31-day month (744 hours, €4.17 uncapped) the worst case for a forgotten hourly server on our entry shape is €4.03 — three cents over the monthly rate. If your provider caps, hourly is a low-risk default for anything you might delete.
- The break-even assumes the server exists the whole month. The real question is existence-hours, not busy-hours — on most providers an idle-but-existing server bills the same as a loaded one. A staging box that exists 8 hours a day on weekdays is at ~24% utilization: clearly hourly territory.
Which workloads fit which meter
Per-second (and short-lived work on any meter)
- CI/CD runners. The 15× example above. Machines that live minutes should be billed in seconds.
- AI agent sandboxes. Agents that provision a scratch VM, execute, and tear down generate exactly the short-lived, unpredictable existence pattern per-second metering was built for.
- Staging and review environments. Spin up per pull request, destroy on merge.
- Batch renders and load tests. Big shapes for short bursts — the case where round-up rounding hurts most, because the hourly rate is high.
These all assume fast provisioning; a pay-as-you-go model is only useful if creating the machine is cheap in time as well as money. Our typical deploy time is about a minute, which is what makes a pay-as-you-go meter worth having at all — and on a rounded-up hourly meter like ours, it is why one runner can churn through a whole queue of jobs inside the hour you already paid for.
Monthly
- Production databases. A database exists 720 hours a month by definition. Take the monthly rate, even if the discount is small.
- Always-on application servers and anything with a public DNS record pointing at it.
- 24/7 streaming origins. A streaming VPS restreaming or looping content around the clock is 100% utilization by design — see our notes on live streaming infrastructure. Monthly, always.
- Long-lived network infrastructure. If you announce your own address space over BYOIP, you are not tearing that machine down after 40 minutes (on our side, BYOIP is a dedicated-server option). Same logic for anything else on dedicated bare metal — sustained heavy load is a monthly (or longer) commitment by nature.
Questions to ask any provider before you deploy
The billing page tells you the rate. These five questions tell you the invoice:
- How do you round? Per-second, per-minute, or partial hours rounded up? For short-lived machines this single answer can move the bill by an order of magnitude.
- Does a powered-off server still bill? On many providers, yes — the disk and IP are still reserved, so "stopped" and "deleted" are different invoices. Hetzner documents this explicitly. If the docs are silent, assume stopped means billing and destroy what you are not using.
- Is there a monthly cap on hourly charges? A cap turns "I forgot to delete it" from a penalty into a non-event.
- How is bandwidth metered? Compute pricing means little if egress is billed separately per GB. Our VPS traffic is unmetered (ports shaped 100–300 Mbps by plan), so a cloud server per hour costs what the hour costs — traffic included. Metered egress can quietly dominate the compute line, especially for streaming or backup workloads.
- What survives deletion? Snapshots, backups, reserved IPs, and detached volumes often bill on their own meters after the server is gone.
The short version
Billing granularity is a spec. Per-second (and second-metered hourly) billing fits infrastructure that scripts create and destroy; monthly fits infrastructure that exists by definition; and hourly-rounded-up is the model to interrogate hardest, because the word "hourly" is doing a lot of quiet work. Run the 714-hour break-even against your actual existence-hours, ask the five questions above, and the right meter usually picks itself.
Ours is on the label: pay per hour, a started hour billed whole, capped at 720 hours a month — from €0.0056/hr on KVM SSD VPS in seven locations across the EU and US, on our own network, AS60982. Pay by card, PayPal, SEPA, or crypto via CoinGate (Bitcoin, Ethereum, USDC, Litecoin and others), with our DPA included in the Terms for GDPR-sensitive workloads and 100 Gbps of always-on DDoS protection included regardless of which meter you choose.