The promise, and the awkward part
"Pay only for what you use" is straightforward until someone runs a server for 31 days. Bill purely by the hour and a month costs 744 hours; bill by the month and an eight-hour test costs a full month. Both are defensible. Neither is what people expect.
So we do both: the meter runs hourly, and the bill stops at the monthly price. Run a server for six hours and pay for six hours. Run it all month and pay the monthly figure, never more.
The ledger
Every instance writes usage records rather than a running total. A record is opened when the server starts and closed when it stops, is destroyed, or crosses a month boundary. Each carries the plan, the hourly rate, and the start and end timestamps.
# one instance, part of a month
instance plan opened closed hours amount
vm-4 VM 4 2026-09-01 09:14:22 2026-09-01 17:02:10 8 ₹15
vm-4 VM 4 2026-09-03 11:40:05 2026-09-30 23:59:59 661 ₹1,349 # cappedStoring records rather than a counter matters because a counter cannot be audited. When someone asks why an invoice says what it says, we can show them the rows. A single accumulating number can only be asserted.
Rounding decision one: the hour
An instance that runs for 61 minutes has used two hours or 1.0167 hours, depending on how you round. We round up to the hour, which is the industry norm and is worse for the customer, so it needs justifying.
The justification is that provisioning and teardown are not free — allocating storage, attaching the network, writing the image, and the reverse on destroy. A server that exists for three minutes still costs real work. Rounding to the hour pays for that without a separate provisioning fee, which we would rather not have.
Where it would be unfair, we do not apply it: an instance destroyed inside ten minutes of creation is not billed at all. That covers the misconfigured order, the wrong region and the typo, which is most of what short-lived instances actually are.
Rounding decision two: the cap
The cap is per calendar month, not per rolling 30 days. That is a real choice with a real consequence, because months are not the same length.
A rolling 30-day cap would mean a server running continuously from 15 January bills a cap on 14 February, then again on 16 March, and the dates drift. Invoices would arrive on different days every month and nobody could reconcile them against anything.
A calendar cap means February is cheaper per hour than January, because the same monthly price covers 672 hours instead of 744. We could have normalised that away. We did not, because "your invoice is the plan price, every month, on the first" is worth more to a customer than three per cent of theoretical precision.
What happens when you destroy a server
Nothing is refunded, because nothing was prepaid. The usage record closes at the destroy timestamp and the month's total stops climbing. If you were already at the cap, the rest of the month is free and you have simply stopped using something you had paid for.
This is the part people expect to be complicated and it is the part the ledger design makes trivial. There is no refund calculation because there was never a prepayment to refund against.
Resizing mid-month
A resize closes the current record and opens a new one at the new rate. The month's bill is the sum, each part capped at its own plan's monthly price, and the total capped at the highest plan you ran.
The last clause is the one worth stating plainly: resize up on the 20th and you are not charged two caps. You are charged one — the larger plan's.
Two places this goes wrong
The first is timezones. If usage records are written in UTC and the cap is evaluated in IST, then for five and a half hours at every month boundary a server accrues against the wrong month. Nobody is overcharged — the amounts move between two invoices — but reconciliation becomes impossible for anyone who checks. It has to be one timezone end to end, including the database column type. Ours is IST.
The second is rounding at the cap. A month's total of ₹1,349.40 must be clamped to the cap, not rounded up past it. Get the order wrong and you take fractions of a rupee off every capped instance, in your own favour. That is small enough to ignore and exactly the kind of thing you should not, because the direction of the error is the whole point. Clamp first, round second.
Why any of this matters
Hosting billing has a reputation it has earned. The way to not deserve it is to make the rules simple enough to state in a paragraph, then implement them so they can be audited line by line.
Ours: hourly meter, monthly cap, calendar month, free under ten minutes, resize costs one cap. The prices those rules apply to are on the pricing page, and if an invoice ever looks wrong, call +91 75994 50220 and we will read you the rows.