# FinOps on Prepaid Credit: ZopCloud Apps Pause at Zero > A prepaid balance only works if the number on screen matches what the apps actually used. ZopCloud shared VMs now run on prepaid credit. Every new user gets ten dollars of free credit with their… Source: https://zop.dev/resources/blogs/finops-prepaid-credit-zopcloud-apps-pause-at-zero Published: 2026-10-09 · Author: riya-mittal · Tags: finops, billing, zopcloud --- A prepaid balance only works if the number on screen matches what the apps actually used. ZopCloud shared VMs now run on prepaid credit. Every new user gets ten dollars of free credit with their first deploy, and apps draw it down by size for as long as they run. Emails go out as the balance passes two dollars and again at fifty cents. At zero, the apps [pause with their data kept](https://zop.dev/resources/blogs/idle-services-vm-sleep-and-wake), and they restart by themselves once a credit pack is bought. Credit is bought, and every charge is listed, under Settings → Billing on the ZopCloud side. Builds on ZopCloud are charged per minute. Builds that ZopDay runs for a customer's own cloud are not. ## Usage Is Pushed From the VM, Not Pulled by the Bill The meter starts on the VM. An OpenTelemetry collector samples container stats every 30 seconds and keeps a six hour file queue, so a short network gap does not drop samples. It posts them to the gateway with a per-VM HMAC token. A tokenless push is refused. The aggregator then checks two things before it counts anything: that the token is valid, and that the organization actually belongs to the space the VM serves. Samples are deduplicated per 30 second step and summed into 15 minute windows. Architecture diagram Each hop owns one decision. The VM only measures. The aggregator only decides what counts. Billing only prices. That split is why a pricing change never needs a collector reinstall. ## A Window Closes on Server Time A 15 minute window is not closed the moment it ends. It closes five minutes later, using the server's clock rather than the VM's. The delay lets late samples from the file queue arrive, and the server clock means a VM with a drifting clock cannot move a charge into a different window. When the window closes, the aggregator hands billing exactly one record per organization per window. Billing prices that record at the rate-card version that was live at the end of the window. A price change made at noon therefore never reprices usage from 11:45. We call this the server-time close: late data gets a fixed grace period, and after that the window is final. ## A Retry Can Never Charge Twice Billing reads the stream in batches of 500 and [debits the ledger](https://zop.dev/resources/blogs/self-serve-billing-needed-an-immutable-price-record) under a key built from the organization and the window. That key is what makes a replay harmless: a record that arrives twice finds its key already committed and changes nothing. | Situation | What the ledger does | |---|---| | Record delivered twice | Second debit finds the key and is a no-op | | Worker dies before commit | Record is not acknowledged and is read again | | Record fails 5 times | Moved to a dead-letter list for a person to inspect | | Acknowledged | Only after the debit has committed | This works when every record carries a stable organization and window. It stops protecting you the moment a record is built without them, which is why one record per organization per window is a hard rule rather than a convenience. ## Builds Are Held, Then Settled From the Real Job Time A build cannot be priced until it ends, but it cannot be allowed to start with no credit either. So a build takes a hold up front. When the run finishes, the settler reads the build job's own timing from GitHub, commits the duration rounded up to whole minutes capped at the job timeout, and releases the hold in the same transaction. Only builds that target a ZopCloud shared space are metered. A build for the customer's own cluster is dispatched unmetered. If the target space cannot be read, the dispatch fails before billing is even asked, so an unreadable target never turns into a free or a wrongly charged build. ## Pause, Don't Delete Crossing zero, or topping up, emits a balance event. The deployer pauses or resumes that organization's apps and answers new deploys with a 402. The apps stop, but nothing is deleted: the worst outcome of an empty balance is a stopped app, not lost data. Buying credit also needs billing details. A new [Billing details](https://zop.dev/resources/blogs/a-hardcoded-payment-callback-was-404ing-on-prod-all-along) drawer in ZopDay Settings → Billing collects legal name, address, country, state, and a GSTIN for India. Buying without a profile opens the drawer, and Save and continue to payment resumes the purchase. Signup credit is granted once per creator, so a fresh account is the only way to get the first ten dollars.