FinOps on ZopCloud Billing: One Row a Day, Not Hundreds
A balance you cannot read is a balance nobody believes. Recent activity in ZopCloud’s Settings → Billing used to list every 15 minute usage charge as its own row, so a single week ran to hundreds of rows.
Recent activity shows one App usage row a day. Click a day to see what CPU, memory, egress and builds cost. Purchases, signup credit, build minutes and expiry keep their own rows.
Day-grain activity is a ledger view that groups usage by the customer’s own calendar day and keeps every other entry type as its own line. The arithmetic shows why it was needed: a charge every 15 minutes is 96 charges a day, or 672 usage rows for a week before any purchase appears.
One Row a Day Follows the Customer’s Calendar
A day is the organization’s day, not the server’s. Usage for a day is the draws plus any debt booked on that day, measured in the organization’s time zone. The edges of a day are daylight-saving safe, so a day that is 23 or 25 hours long is still one row.
| Kind of entry | How it appears |
|---|---|
| App usage | One row a day |
| Purchases | Own row |
| Signup credit | Own row |
| Build minutes | Own row |
| Expiry | Own row |
Only the repetitive entry type is collapsed. Events that a person recognizes, such as buying credit, stay visible as their own lines so the list still reads like a statement.
You pick a date range of up to 92 days, and preset ranges use the organization’s time zone too. The page moves through the range by day instead of by raw entry.
A Day Breaks Down by Meter From the Charge Snapshot
A day’s row is a total, and the breakdown behind it comes from the charges themselves. Each charge carries a snapshot, and the per-meter totals for CPU, memory, egress and builds are summed from those snapshots.
Two cases are handled openly. A meter with no price reads “not charged” instead of showing zero cost as if it had been priced. And a charge with no snapshot still counts toward the day’s total, so a missing detail never makes the day look less costly than it was.
Bounded Reads Keep the Ledger Fast
A new billing read returns the grouped activity for a range. It accepts a start, an end and a time zone, and the customer route redacts the actor and the grant reason, the same as the existing entries route does.
One read covers at most 92 days and 100,000 entries. Beyond either, the answer is a 400, so no single request can ask the ledger to scan without end. The read uses an index that already existed for the account’s entries, and no migration was needed.
This works when a range fits inside those bounds. A longer history is read in several ranges, which is why the page pages by day and the picker stops at 92.
