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.
We run hourly VPS ourselves — prices quoted per hour, metered to the second — 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, metered finer than an hour. Our model: the price is quoted per hour, but usage is metered to the second. The phrase on our pricing page is literal — "Pay per hour. Billed to the second." — and hourly usage is capped at the shape's monthly price, so a per-hour server never costs more than its monthly equivalent.
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.006/hr, 100 rounded-up hours is €0.60/day versus €0.04 metered to the second. Nobody rage-quits over 56 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.006/hr hourly, or €4/mo monthly. A nominal month is 720 hours.
- Full month at hourly rate: €0.006 × 720 = €4.32
- Monthly plan: €4.00
- Break-even: €4.00 ÷ €0.006 ≈ 667 hours, about 93% utilization
Below 667 hours a month, pay-as-you-go wins. Above it, monthly wins — by about 8% 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. Both Hetzner and we cap hourly charges at the monthly price, so the worst case for a forgotten hourly server is the monthly rate, not €4.32. If your provider caps, hourly is a strictly-no-worse 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 / second-metered hourly
- 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 median deploy time is 47 seconds, which is what makes second-level metering worth having.
Monthly
- Production databases. A database exists 720 hours a month by definition. Take the ~8% discount.
- 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. Same logic for anything 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 ship with 1 Gbps unmetered, 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 667-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, billed to the second, capped at the monthly price — from €0.006/hr on KVM NVMe VPS across 13 POPs in the EU and US, on our own network, AS60982. Pay by card, SEPA, or crypto (Bitcoin, Ethereum, USDT), with DPAs signed as standard for GDPR-sensitive workloads and free always-on 1 Tbps DDoS mitigation regardless of which meter you choose.