Your CloudAMQP plan says $99 a month, but the invoice says $82.33, and next month it says $114.07, and you never changed anything except resizing an instance on a Tuesday. Nothing is wrong. CloudAMQP does not sell messages. It sells instance time by the second, bills a month in arrears, and prorates every plan change to the exact second it happened. The sticker price is a speed limit, not a promise. Until your books treat the invoice as a meter reading rather than a subscription, your infrastructure costs will drift, your accruals will miss, and your gross margin will quietly absorb the difference.
This post explains how CloudAMQP actually meters and bills, what realistic bills look like, why the production broker belongs in cost of goods sold, and how to reconcile instance-time invoices so every dollar lands in the right account.
How CloudAMQP Meters: Time, Not Messages
CloudAMQP is managed RabbitMQ and LavinMQ hosting run by 84codes. You pick a broker, a plan, and a region, and you get an instance or a cluster. The billing model follows the instance, not the traffic flowing through it, which is the opposite of per-request messaging services where the payload size drives the bill. Here the two questions that determine your invoice are how big an instance you ran and for how many seconds.
Shared plans have quotas, dedicated plans have capacity
The shared multi-tenant plans are the only place message counts appear at all. Loyal Lemming is free with a 2 million message monthly quota and 40 connections, and Elegant Ermine costs $19 a month with a 20 million message quota and 200 connections. These suit development, prototypes, and hobby projects. The quota is a ceiling, not a meter: you do not pay per message inside it.
Dedicated plans drop message counting entirely. You get your own broker or a multi-AZ cluster of them, and every dedicated plan runs the same engine at the same speed. You pick a tier by how much your system holds: connections, queues, and stored messages. The single-node LavinMQ ladder runs from Passionate Puffin at $49 a month through Playful Penguin at $99, Lively Lynx at $199, and Wild Wolverine at $499, with larger tiers above that. One, three, and five-node cluster shapes trade price for availability. Data transfer is included within a fair-use allowance, which the pricing page defines as free transfer equal to 30 percent of your team spend each month. If you exceed it, you get 30 days to resolve the overage before traffic charges start appearing on later invoices.
The practical consequence: your message volume can double without moving the invoice a cent, as long as the instance still holds the connections, queues, and backlog. Conversely, upgrading to a bigger tier because one limit pinched you reprices every second from that moment on, even if traffic is flat. Capacity planning, not traffic forecasting, is the skill that controls this bill.
Every second counts, and the bill arrives a month late
All plans are billed by the second. At the end of each month your bill reflects the exact time each instance was available for use, so an instance created mid-month, deleted mid-month, or resized mid-month produces a prorated charge rather than a full or zero month. You can switch plans at any time without downtime, and autoscaling between tiers has the same effect: each segment of the month prices at the tier that was live during those seconds.
Payment happens the month after delivery. CloudAMQP's own FAQ puts it plainly: billing is pro-rated, customers pay only for the time the service was available to them, and you receive your first invoice at the beginning of the upcoming month rather than at signup. That arrears rhythm is the single most important fact for your books. There is no charge at close to book against, which means every month-end close needs an accrual for unbilled broker time, and every invoice needs a true-up against last month's estimate.
Two more billing mechanics matter. First, prepayment: you can prepay one to several months in advance, and a prepayment is valid for one year before it expires. A customer on a $99 plan can prepay twelve months and skip monthly charges for a year, and the credit covers every plan on the account, so adding a second instance draws it down faster. That is a prepaid asset with a one-year fuse, not an expense at payment time. Second, there is no annual invoice. Because customers change plans so often, CloudAMQP does not offer yearly billing; prepayment credit is the substitute. If your procurement process demands an annual invoice or separate purchase orders per subscription, plan around this early: separate POs require separate accounts so the subscriptions bill separately, and invoicing terms go through their billing team rather than the self-serve card flow.
Marketplace instances bill through the platform, not CloudAMQP
If you provisioned through Heroku add-ons or the AWS, Azure, or GCP marketplaces, the spend does not appear on a CloudAMQP invoice at all. It lands on the platform bill, Heroku's monthly invoice or your cloud provider's cost breakdown, under that platform's naming. This is the most common reconciliation gap for teams running brokers in two places: the direct invoice reconciles cleanly while the marketplace twin hides inside a larger cloud bill, often classified as generic hosting. Decide once where each instance bills from, and make sure your month-end pull covers both the CloudAMQP control panel and every marketplace it could hide in.
What This Costs at Realistic Shapes
List prices only make sense multiplied by seconds, so here are three shapes built from published single-node prices.
A side project runs staging on the free Lemming tier and a Puffin at $49 for a small production service. The broker line is $49 a month, flat, and the only reconciliation task is confirming the instance ran the whole month.
A growing SaaS team runs production on a Penguin at $99 and staging on an Ermine at $19. Mid-month, queue depth forces an upgrade: Puffin-level staging stays put, but production moves from Puffin at $49 to Penguin at $99 ten days into a thirty-day month. The production leg prices as ten days at the lower tier plus twenty days at the higher one, roughly $16.33 plus $66.00, or about $82.33, and staging adds $19. The invoice total lands near $101.33 for a setup whose sticker prices sum to $118. Next month, with Penguin live for the full period, the same setup bills the full $118. Anyone booking the sticker price both months overstates the first month and understates nothing the second, which is exactly the drift that per-second billing punishes.
A larger shop runs a three-node production cluster plus staging and a prepaid credit balance. The cluster multiplies the single-node rate, plan changes during incident response add prorated segments, and the prepayment absorbs the total without a card charge. The invoice still itemizes every instance and every segment, and the credit drawdown is the number to book, not the zero on the card statement.
None of these shapes involve message counts. If your finance model multiplies expected messages by a per-message rate, it is modeling a different vendor. Model instance tiers multiplied by expected seconds, and revisit the tier assumption whenever connection or queue growth forces a resize.
Why the Production Broker Is COGS, Not Overhead
A message broker that carries order events, job dispatches, and customer notifications in production is a direct cost of delivering your product. It scales with the business, it stops mattering the moment nothing sells, and it sits naturally above the gross-margin line alongside compute, database, storage, and bandwidth for production. SaaS gross-margin practice applies a direct-cost test: spend that exists to serve customers in production is cost of revenue, while spend that builds, sells, or administers the company is operating expense. Classic SaaS runs 75 to 85 percent gross margin on this basis, with infrastructure-heavy businesses running lower, and investors benchmark you against those bands.
Apply the test instance by instance, because one CloudAMQP account usually holds several. Production brokers carrying customer workloads pass into cost of goods sold. Staging, load-test, and developer sandbox instances fail into research and development or general overhead. The shared Ermine running your staging environment is not COGS just because it shares an invoice with the production Penguin. The invoice lumps them together, so split it every month by instance, using the control panel's per-instance breakdown. Teams that skip the split usually err in the flattering direction, burying infrastructure in overhead and reporting a margin their unit economics cannot defend. A diligence review reclassifies it in an afternoon, and the restated margin is never the higher one.
The accounting standards back this up. Under ASC 350-40, a managed hosting arrangement where the vendor runs the software is a service contract, and the fees are expensed as incurred over the usage period. Implementation work can have its own treatment, but the monthly instance-time charge is a period expense, never a capitalized asset. Prepayments are the mirror image: cash out today, expense later, so the prepayment sits as a prepaid asset and releases into expense as the credit is consumed. Booking the prepayment as expense on payment day overstates the payment month and understates every month the credit covers.
Book the net amount you actually pay. The free Lemming tier is free capacity, not revenue, so there is nothing to gross up. If you want visibility into what the workload would cost without it, track that in your metrics and keep the ledger at cash cost.
How to Book It So the Invoice Reconciles
Give the broker its own cost-of-sales account rather than blending it into generic cloud or software spend. A dedicated account such as message broker lets you divide the month's production spend by the month's instance-seconds and see your true cost per unit of capacity, which is the number that tells you whether a resize bought headroom or just a bigger bill.
Because billing runs a month in arrears, the rhythm is accrue, then settle, then true up. Estimate the broker portion from instance tiers and seconds at close, split production from staging, and correct to the invoice when it lands. Here is a full cycle for a month where production ran $82.33 after a mid-month resize and staging added $19.00:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:CloudAMQP USD
2026-01-01 open Expenses:CostOfSales:Message-Broker USD
2026-01-01 open Expenses:Research:Staging-Infra USD
2026-01-01 open Liabilities:Accrued:CloudAMQP USD
2026-01-31 * "CloudAMQP" "January estimate, prod Puffin-to-Penguin resize plus Ermine staging"
Expenses:CostOfSales:Message-Broker 82.33 USD
Expenses:Research:Staging-Infra 19.00 USD
Liabilities:Accrued:CloudAMQP -101.33 USD
2026-02-04 * "CloudAMQP" "January invoice settles, estimate was exact"
Liabilities:Accrued:CloudAMQP 101.33 USD
Assets:Cash:Operating -101.33 USDWhen a prepayment covers the month, the settlement leg draws the prepaid asset instead of cash. Record the prepayment as an asset when you pay it, then release each month's consumption:
2026-01-05 * "CloudAMQP" "Prepay 12 months Big Bunny at 99 per month"
Assets:Prepaid:CloudAMQP 1188.00 USD
Assets:Cash:Operating -1188.00 USD
2026-01-31 * "CloudAMQP" "January consumption against prepayment, prod plus staging"
Expenses:CostOfSales:Message-Broker 82.33 USD
Expenses:Research:Staging-Infra 19.00 USD
Assets:Prepaid:CloudAMQP -101.33 USDTrack the prepayment's one-year expiry the way you track any use-it-or-lose-it credit. An expiring balance is a real loss, and it deserves a calendar reminder, not a discovery during next year's cleanup. If you keep your books in plain text, the cost-tracking patterns in the docs extend naturally to a per-instance broker split.
One classification trap: a data-transfer overage surcharge and a bigger tier are both broker costs, but they mean different things. The tier change is planned capacity; the overage is unplanned burn past the fair-use allowance. Book both to the broker account, but tag or memo the overage separately so the month it appears reads as an exception rather than a new baseline.
Five Controls That Keep Instance-Time Honest
Per-second billing rewards attention and punishes set-and-forget. These five controls catch the common drifts.
1. Reconcile instance by instance, not invoice by invoice
Match each invoice line to an instance you recognize, at a tier you authorized, for seconds that roughly cover the month. A line for an instance nobody owns is usually a forgotten staging broker or a load-test cluster from three sprints ago still billing by the second. Delete ruthlessly; there is no reward for idle capacity here.
2. Log every resize with its timestamp
Each plan change splits the month into priced segments. Keep a lightweight change log, even a shared note with date, instance, old tier, and new tier, and reconcile the invoice's segments against it. Without the log, a blended total like $82.33 is unverifiable arithmetic. With it, the math checks in a minute.
3. Pull marketplace spend into the same review
If any instance bills through Heroku or a cloud marketplace, add those lines to the same monthly review as the direct invoice. Name the marketplace in the ledger narration so next month's reviewer does not hunt for a CloudAMQP line that will never exist. This is also where duplicate billing hides: an instance migrated from marketplace to direct billing sometimes runs double for a few days.
4. Watch the fair-use transfer allowance before it bills
Data transfer is included up to 30 percent of team spend, with a 30-day resolution window after an overage before surcharges hit later invoices. Treat the first overage notice as the control, not the surcharge. Check which instance's traffic spiked, confirm it is legitimate growth rather than a retry storm or a chatty consumer, and resolve it inside the window. A retry loop that fans out across a cluster can convert a quiet month into a transfer overage without changing any tier.
5. Automate the pull
The control panel lists every invoice, and the customer API exposes invoice operations alongside instance management, so the month-end pull does not have to be a human clicking through a console. Script the download, parse the per-instance lines, and compare against your change log and your accrual. The accrual estimate itself can come from the same data: tier rates multiplied by seconds elapsed, which beats guessing from last month's total whenever a resize happened mid-cycle.
Month-End Checklist for Broker Costs
Close the loop the same way each month so the numbers stay trustworthy:
- List every instance and cluster, direct and marketplace-billed, and confirm each one still has an owner and a purpose.
- Reconcile each invoice line to an instance, tier, and time segment, using your resize log for any blended totals.
- Split production from staging and sandbox spend, and confirm only production landed in cost of goods sold.
- True up last month's accrual to the settled invoice and carry the variance forward into next month's estimate.
- Draw down any prepayment by actual consumption, and check the remaining balance against its one-year expiry.
- Confirm transfer usage stayed inside the fair-use allowance, and resolve any overage notice inside its 30-day window.
- Confirm every instance created during the month inherited the right environment tag and landed in the right account from day one.
Pull this month's CloudAMQP invoice today and match each line to an instance you can name. If every line maps cleanly, your broker accounting is honest. If one does not, you just found either a forgotten instance still billing by the second or a marketplace twin hiding in another bill, and either discovery pays for the review.
