Plans & Billing

noBGP bills one flat plan price per organization, plus two meters: bandwidth and provisioned compute. Everything else — nodes, networks, services, members, storage — is a plan limit, not a charge, so it can never move your bill; and from router 0.4.106 only storage is a limit you can actually reach, since nodes, networks, services and members are unlimited on every plan. There are no per-seat charges: invite as many members as you like, on any plan including Free. On a paid plan the two meters are paid from a usage-credit balance your organization buys and holds, so the subscription invoice itself is the flat plan price and nothing is added to it that an Owner did not ask for — automatic top-ups are bounded by your spend cap, which starts at $0. Free is hard-capped instead and can never produce a bill at all.

Plans

Plan	Price (per org)	Bandwidth	Compute included	Nodes	Storage	Bandwidth overage
Free	$0	50 GB / mo	$1 / mo	unlimited	10 GB	none — traffic stops instead, no bill, ever
Pro	$20 / mo ($200 / yr)	100 GB / mo included	$5 / mo, then from $0.02 / h	unlimited	100 GB	$0.12 / GB
Business	$200 / mo ($2,000 / yr)	1 TB / mo included	$50 / mo, then from $0.02 / h	unlimited	1 TB	$0.10 / GB
Enterprise	Custom	Committed	Negotiated	Committed	Custom	Negotiated

Nodes, networks, services and members are unlimited on every plan — Free included, from router 0.4.106. Annual billing is 10× the monthly price — about two months free. Allowances are flat per organization regardless of team size.

⚠ Included compute is a dollar amount, not a number of hours. It is one budget, spendable on any class at any concurrency, at the class rates. $1 is 50 hours of a small machine ($0.02 / h), $5 is 250 hours and $50 is 2,500 hours — or a third as many hours of a medium machine. On a paid plan, compute continues past the included amount and is paid from your credit balance at the same rates, so the included amount is not a limit there. On Free, the included amount plus any promotion that is still live is the whole budget.

New compute allowances

The included compute rises, on the same plan prices: Free from $0.50 to $1, Pro from $1 to $5, and Business from $20 to $50 a month (in hours of a small machine: 25 to 50, 50 to 250, and 1,000 to 2,500).

• It is live since 15 September 2026 (UTC), with no action from you. Every organization gets the whole new amount for the current month, this one included — a paid organization that subscribed part way through the month is not prorated for this change.
• Free organizations, and any organization that has never subscribed, get it within about five minutes of the change, at the next allowance sweep. A paid organization that had subscribed before got it at the moment the change was applied, with the rise recorded in its audit log.
• An organization with a compute limit of its own keeps that limit. A limit set for one organization is not overwritten by a catalogue change.
• From the next month, every organization gets the whole new amount at each monthly reset. A plan change part way through a month is still prorated, as before — raise your plan mid-month and you get the larger of what you already hold and the new plan's amount for the part of the month that is left.
• Traffic, storage and prices do not change.

Launch promotion: $10 of compute and 200 GB, for 60 days

Every account gets this once, on its personal organization, on top of its plan (an organization that existed on the day paid plans went live got one of its own):

Compute	$10 — 500 hours of a small machine
Traffic	200 GB

• It lasts 60 days and does not renew. What is left at the end of the 60 days is gone.
• An organization that existed on the day paid plans went live got it on that day, and it expires on 11 November 2026 (UTC). Its compute part rises from $5 to $10, with the same expiry date. Compute that you already used stays used; the rise adds to what is left.
• A new account gets it within about five minutes of being created, through 31 December 2026, and it expires 60 days later. It goes to the account's personal organization.
• It is extra, not a plan change. Your plan, its storage limit and its compute deadline stay the same, and your plan's own monthly amounts keep arriving.
• The amount that expires first is spent first. See The allowance that expires first is spent first.

A gigabyte here is 1,000,000,000 bytes

Every bandwidth and storage allowance on this page, and every per-gigabyte rate, is denominated in decimal units — 1 GB = 10⁹ bytes, 1 TB = 1,000 GB. So Free's 50 GB of traffic is 50,000,000,000 bytes and Business's 1 TB of storage is 1,000,000,000,000, and $0.12 per GB on Pro buys 10⁹ bytes of overage.

Router 0.4.112 is where the numbers behind these words became those numbers. Until that release the allowances were stored as binary quantities — 50 GiB, 100 GiB, 1 TiB — so every organization received about 7.4% more than the page promised, and the overage rate bought 2³⁰ bytes rather than 10⁹. Nothing has ever been charged against the old figures, which is why this is a number being set rather than a repricing; after a first invoice it would have been a reduction that needed telling people about instead.

Machine memory under Provisioned compute is quoted in GiB, which is the usual unit for RAM and is deliberately not the same thing.

The usage screen in the web app reads the same decimal unit, so the screen and this page agree. For a short window after router 0.4.112 they did not: the screen was still dividing by 1,024, so it read about 7% low against the allowance stated here. That window has closed, and the allowance and the bill have always been the numbers on this page.

Two prices read "$200", and the period is what tells them apart

Pro's yearly price and Business's monthly price are the same number. Every price on this page carries its billing period for that reason; read the period before comparing them.

Business is back, at a different price and shape

Business was retired at $99 / mo with the one-meter model in router 0.4.101, and returns in router 0.4.103 as a $200 / mo plan — 1 TB of bandwidth, 1 TB of storage and 1,000 hours of compute included (now $50), with overage bandwidth at $0.10 / GB. It is a new plan reusing the old name, not the old one restored: nothing about an organization that was on the retired plan changes, and historical invoices are unaffected.

It is not a traffic discount for most organizations. Below roughly 4.6 TB a month (3.1 TB if both plans are paid yearly), Pro with overage costs less. What Business buys is a flat bill for heavy usage, 1 TB of storage — which Pro cannot reach at any price — and $50 of compute a month.

Self-serve checkout for Business is open, monthly or annually, alongside Pro — the sellable set comes from the plan catalogue rather than a fixed list, so it is the plan row that says what may be bought. Questions about fit, or about a committed volume larger than Business includes, go to Enterprise.

Pro moved from $19 to $20 / mo ($190 to $200 / yr) in router 0.4.103, with every allowance unchanged.

Checkout and payment management use Stripe-hosted pages, reachable from Account → Billing in the web app, which also shows live usage against each allowance.

Your plan, your card and your invoices

One read answers what a billing page asks, from router 0.4.114: the billing operation on the REST surface — POST /api/v1/tools/billing with org_id — returns the organization's plan (as its catalogue plan_id, empty for an organization on no plan), its subscription status, when the paid period ends, the payment method that will be charged and a page of invoices with links to view or download each one. It is Owner only, like every other billing action, and it changes nothing.

Money data is the Owner's, from router 0.4.179

Invoices, the card, the credit balance and the spend cap are readable by the Owner alone — in the app as well as through the tools, because the database withholds those columns rather than only the tool refusing them. Which plan and interval the organization bought is not money data: an Admin sees that, including in the audit log, where the amounts are stripped from the rows an Admin reads. Usage — compute, bandwidth, storage, per node — stays readable by every member, since the people running the work are the ones who need to see what it costs. ::: Ask for more invoices with invoice_limit (10 by default, 100 at most) and page with invoice_starting_after, passing the id of the last invoice you were given; has_more_invoices says whether another page exists.

⚠ cancel_at_period_end is the field to read beside the status, not instead of it. Stripe leaves a cancelled subscription active until the period actually ends, so the status alone tells someone who has just cancelled that their plan renews — for up to a month, about their own money. active and cancel_at_period_end: true means ends on, never renews on.

⚠ It is now set for a cancellation made in the billing portal too, from router 0.4.127. Stripe records the two kinds of cancellation in two different fields — a portal cancellation sets an end instant and leaves its own cancel_at_period_end false — and noBGP read only one of them, so every real customer cancellation reported false: the one shape a person actually produces was the one shape the field could not see. Both are read now, and either answers true.

interval says whether the subscription is billed monthly or annually, from router 0.4.133 — month or year, and empty for an organization that has no subscription. It is read from the price you subscribed to, not inferred from the period, because the period cannot tell you: an annual plan renews on its own anniversary while its included allowances still reset on the first of each calendar month, so the distance between today and current_period_end says nothing about which interval you bought.

customer_balance_cents is the balance Stripe holds for your organization, from router 0.4.134, carried with Stripe's own sign: a negative figure is credit you are owed and is applied automatically to your next invoices, a positive one is an amount outstanding, and zero means there is nothing either way — including for an organization that has never subscribed. It is copied as Stripe reports it rather than flipped to read as a positive credit, because a reader that also knows Stripe's convention would then show the money twice.

It is the one place on this surface a proration credit from a plan change can be seen — moving off a prepaid year credits the months you have not used, and that credit lands here.

⚠ It is not your usage-credit balance, and the two are spent on different things. credit status's balance_cents is the credit your organization buys to pay for bandwidth and compute past its included allowances; customer_balance_cents is money Stripe holds against your invoices, and it is applied to the next one automatically rather than drawn down by usage. Neither figure moves the other.

The payment method and the invoices are read from Stripe on every call and are never stored here, because both can change on Stripe's own pages without noBGP being told. An organization that has never subscribed has no method and no invoices, and says so with an empty list rather than an error.

What running out of credit or lapsing would do

consequences is three booleans naming what this router applies to an organization that has lapsed or drawn its credit balance to nothing, from router 0.4.133. It is always present:

Field	True when
refuse_create	New nodes, networks and services are refused — and so are agent registration and provisioning
stop_compute	Provisioned machines are stopped
slow_bandwidth	Bandwidth is slowed

⚠ They describe the router, not your organization. Every organization on the same router gets the same three answers, and each one is true of you only while you are actually lapsed or out of credit. Read them as what would happen, never as what is happening to me.

The three are governed separately, so it is normal for one to be true and the others false — the creation refusal applies today, while the compute stop and the slowdown wait on enforcement being switched on. That is why they are three booleans rather than one: a surface that collapsed them would have to pick one of the three to be wrong about.

They are the same three facts the billing alert emails are written from, which is the reason they are on this payload at all: a banner that worked them out for itself could tell you your machines were stopped in the same hour as a mail telling you they were not.

Which payment method gets charged

payment_method is the method noBGP would actually charge, resolved in one order: the customer default — the method you last chose in the billing portal — else the method your subscription is set to charge, else the only method attached. From router 0.4.120 a credit purchase resolves it the same way, so what you are shown and what you are charged cannot disagree — before that release it read the customer default alone, and subscribing through checkout sets the method on the subscription, so a purchase could be refused as having no saved card while a subscription was charging that very card every month.

⚠ The customer default comes first from router 0.4.130, and through router 0.4.129 it came second. The two fields are written by two different things: checkout sets the method on the subscription, and Stripe's billing portal — the only place you can change a card — sets it on the customer and never touches a subscription that already carries one. So the subscription's method is the card frozen at the moment you subscribed, and the customer's is the card you last chose. Reading the subscription first meant that changing your card showed you the old one and charged your credit purchases to the old one, including every automatic refill; an expired card there declined every attempt for an organization with a good card on file. The subscription stays as the second source, so an organization that checked out and never opened the portal is still answered.

⚠ A completed checkout now also sets the customer default, from router 0.4.130, so the two fields agree from the start rather than only after your first portal visit.

⚠ And from router 0.4.134 it sets it even when that field already names a card. Completing checkout is you choosing a card, so the card you just entered wins over whatever the field held from an earlier subscription. Through router 0.4.133 it was written only when the field was empty — which meant a returning customer was charged the card they had left behind: cancel a subscription paid by Stripe Link, subscribe again with a typed card, and the customer default was left on Link while the clear below removed the only field that named the new card. The first invoice went to the new card and every one after it to Link.

⚠ The narrow cost of that is a card change made while a checkout is still being confirmed. noBGP is told a checkout completed by Stripe, and a delivery that fails is retried for up to three days; if you change your card in the portal inside that window, the confirmation can still land afterwards and put the checkout's card back. Re-enter the card you want from Account → Billing if a checkout and a card change cross like that — the billing read always shows which method would be charged.

And from router 0.4.133 a completed checkout then clears the method off the subscription, leaving the customer default as the only one either side holds. That closes the split below at its source: with nothing on the subscription, Stripe charges every plan invoice to the customer default — the one field the billing portal writes — so changing your card changes what your next plan invoice is charged to, not only your credit purchases. The clear happens only after the customer default is confirmed to hold a value, so there is never a moment when neither field names a card.

⚠ It applies to checkouts from that release onward, not retroactively. A subscription that was created earlier still carries its own default until you subscribe again, so for those the split below is unchanged. Every reader still resolves your card through the order above either way.

⚠ On an older subscription, Stripe charges a plan invoice to the method held on the subscription, and that is not something this field can change. After changing your card in the portal, credit purchases and this field use the new method while the next plan invoice may still be charged to the old one. Removing the old method from Account → Billing is the way to be sure; if a plan charge lands on a method you replaced, tell us.

⚠ It is null when several methods are attached and none is set as the default — naming one would be a guess about which Stripe picks — and when there is no method at all. Set a default in Account → Billing.

⚠ A payment method is not always a card. Stripe Link and a bank account are methods too; type says which, and anything other than card carries no brand, last four digits or expiry — account names it instead (the Link account's email, or the bank's name). Read type first.

Changing any of it opens a Stripe page. create_billing_portal takes an optional flow from router 0.4.114 so you land on the action instead of the portal's front page: payment_method_update to change the card, subscription_update to change the plan, subscription_cancel to cancel. The last two act on a subscription and are refused for an organization that does not have one. Every flow returns to the app's billing page when it finishes, and card details are entered on Stripe and never on noBGP.

Changing plan once you already have one

Checkout buys a first subscription; after that a plan change goes through the billing portal. create_checkout refuses an organization whose subscription is active or past_due — a second checkout would open a second subscription against the same customer, which is two bills for one organization — and the refusal names the portal. A subscription that has been cancelled can go through checkout again, because there is nothing left to change.

From router 0.4.129 the portal's plan chooser offers every plan noBGP sells, monthly and annually, so a Pro organization can move to Business and back again. Through router 0.4.128 it offered only the plan you already had: the chooser was left with no list of products, which Stripe reads as offer the current one rather than offer everything — so the one page whose purpose is changing your plan had your current plan as its only choice, and subscription_update was a flow with nowhere to go.

Each plan's card in that chooser now carries its own summary — included traffic and the rate past it, storage, and included compute — generated from the same catalogue the table above is checked against. Through router 0.4.128 Business carried a hand-written line and Pro carried none at all, which is precisely the moment you are comparing the two.

A plan change is settled immediately, from router 0.4.134. Stripe invoices the difference between the two plans at the moment you switch rather than holding it back for your next invoice:

• Moving down — Business to Pro, or annual to monthly — credits the time you have paid for and are not using. It becomes a credit note and a credit on your organization's balance, visible in the portal's invoice history and readable as a negative customer_balance_cents, and it is applied to your next invoices automatically. ⚠ The portal's confirm page shows Amount due today $0.00 for a credit — Stripe's preview floors a credit at zero — so the invoice list is where the amount is.
• Moving up, or any mid-period difference on a monthly plan, is invoiced there and then and charged to your payment method; Amount due today on the portal's confirm page is that number. ⚠ A card that declines it is an ordinary failed payment, with the grace, the mail and the dunning that follow one — it is not silently deferred.
• Both appear under Invoices in the app the moment the change lands, from app 0.18.0 (measured 2026-09-06): a credit shows as a negative amount, and the balance it left is printed beneath the list.

⚠ Through router 0.4.133 that money waited for the next invoice, which on an annual plan is a year away. Measured on 6 September 2026: a Business annual organization ($2,000 paid) moving to Pro annual was owed $1,800 that existed on no page at all — not in the portal, not in the app, and not in the balance the billing read returns, which showed 0. An annual-to-monthly switch stranded $1,980 the same way, to be drawn down $20 a month for eight years. Nothing was lost in either case; it was simply unreadable and unspendable until its invoice came round (router#1315).

⚠ A switch cannot bill the same gigabytes at both plans' rates. Pro's overage price and Business's pointed at one meter, and through router 0.4.128 a switch attached the new plan's price without taking the old one off — so a subscription carrying both counted every gigabyte twice, at $0.12 and $0.10, and upgrading raised your overage rate. Router 0.4.129 removed the old plan's metered lines when the switch landed; from router 0.4.132 there is nothing to remove, because usage is never invoiced and no metered price is attached to a subscription at all.

⚠ No organization on noBGP's own routers could reach that in the first place, because usage there has been paid from credit since router 0.4.123 and the router attached no metered line even then. Lines left over from the meters retired in router 0.4.101 belong to no plan, are left alone, and still invoice nothing.

⚠ The chooser, and when a plan change is invoiced, are both configuration of noBGP's hosted billing pages rather than something in the router build. A self-hosted deployment billing through its own Stripe account configures its own portal — including whether a switch is settled at once — and does not inherit either from the release.

One billing day: the first of the month

Every monthly subscription bills on the first of the month, from router 0.4.109. A billing period is a UTC calendar month, and it is the same month everywhere: your invoice covers it, your included bandwidth and compute reset with it, the spend cap is measured across it, and the usage page shows it. There is no per-organization anniversary to remember.

An annual plan is paid in full on the day you subscribe and renews on that same date a year later — it is not moved onto the first, and it is not prorated. Proration is computed against the price's own interval, so anchoring a yearly price to the first would charge a few days out of 365 at checkout — about $14 of a $200 year bought on the 5th — and then the whole year at the turn of the month. You press a button that says $200 a year and you are charged $200. Your included bandwidth and compute still reset on the first of each calendar month, exactly as on a monthly plan: what the interval changes is when you pay, not when the allowances come back.

Subscribing mid-month costs a part-month and includes a whole one — once per organization. Checkout charges a prorated amount for the days between subscribing and the first, then a full plan fee each month after. ⚠ The allowance for those days is not prorated on a first-ever subscription: you get the whole month's included bandwidth and compute for a part-month's fee, deliberately, because a prorated allowance is a number you could neither predict nor check. Every organization subscribing for the first time gets that, however late in the month it starts.

A later subscription counts the days it pays for, from router 0.4.113. Cancel and subscribe again — this month or a year from now — and that month's included bandwidth and compute are scaled to the part of the month that remains, because the whole month for a part-month's fee is a welcome bonus rather than something to take every month.

⚠ Subscribing again never lowers what you already have. The prorated figure is floored at whatever that period's allowance already holds, so moving from Free to Pro three days before the end of a month leaves your allowance where it was rather than reducing it — three days of Pro is worth less than the month of Free you are already holding. An upgrade can only ever raise it.

Free is never prorated, on either path: nothing is charged for it, so there is no part-month fee for a part-month allowance to match.

Before router 0.4.109 a subscription billed on the anniversary of its own checkout while allowances still reset on the first, so the two never lined up: the spend cap was measured within a calendar month — it bounded overage in those releases — and a Stripe invoice spanning two partial months could contain two of them — a $50 cap on a $100 invoice. Nothing on the usage page reconciled with what was charged, either.

An annual plan renews on its own date; the spend cap is still monthly

The spend cap is measured against a calendar month, and a year spans twelve of them — so a $50 cap admits up to $600 of automatic credit refills over the year an annual subscription covers. That was true when annual subscriptions were anchored to the first, and it is true now that they renew on their own anniversary. On an annual plan, read the cap as per month, which is what it has always been.

Checkout near the end of a month is handled from both sides, on the monthly interval. Stripe creates the subscription when you complete checkout, not when the page opens, so a session started at 23:50 on the 31st could otherwise be anchored to a moment that had already passed by the time you paid — a failure at the payment step, which is the worst possible place for one. An annual session is anchored to nothing, so none of this applies to it and it keeps Stripe's ordinary 24-hour window.

• A session opened within about half an hour of the boundary is anchored to the following month's first instead. You pay a longer proration at checkout and get both months' included allowances for it.
• A session opened within a day of the boundary expires at the boundary rather than outliving its anchor. If one lapses before you finish, start checkout again from the billing page and it anchors to the next one.

Switching from annual to monthly puts you back on the first

A subscription keeps the billing day it was created with, so converting an annual plan to a monthly one used to leave you billing on a day that is not the first — and from router 0.4.134 noBGP moves it back. The portal's plan chooser changes the price on the subscription you already have, and Stripe keeps that subscription's existing anchor, which for an annual plan is the instant you first checked out: a plan bought at 07:07 UTC on 6 August then billed on the 6th at 07:07 every month, while the included allowances, the spend cap and the usage page all went on running over the calendar month. That is the same mismatch router 0.4.109 removed for a monthly checkout, arriving through a different door. ⚠ Through router 0.4.133 the anniversary stood, and the invoice month and the usage month disagreed for that organization (router#1316).

The new cycle starts on the first of the month at or after the date you have already paid through, and the days in between are free. The switch invoices a month from the old anchor, so a subscription paid through 6 October restarts on 1 November — those 25 days are not charged, not prorated and not re-invoiced, and its included bandwidth and compute still reset on 1 October as they always did. Restarting on 1 October instead would take back five days you had already paid for.

⚠ Only a live monthly subscription is moved. An annual one is left where it is, because an annual plan renews on its own anniversary deliberately; so is one already billing on the first, one you have set to end — moving the cycle would move the end date you confirmed — and one that is not paid up. Your plan, your allowances, your card and your credit balance are untouched: what changes is the day the invoice lands.

⚠ Stripe records those free days as a trial, because a trial ending on a chosen date is how a billing day is moved. Your subscription still reports active in the billing read throughout, which is what it is — you are paid up for every day of it.

The meters

There are two, and they are the only two things you do that cost us money in proportion to how much of it you do:

Meter	What it counts	Where it is charged
Bandwidth	Every byte your nodes move through noBGP's infrastructure, in both directions	Over your plan's included allowance, at the plan's rate
Provisioned compute	Running time of nodes you provision on noBGP's own capacity, by the minute	Over your plan's included compute, at the class rate

Both are netted against the plan's included allowance first, and past it both are paid the same way: on a paid plan they are drawn from the organization's credit balance at the rates above. Nothing else on any plan can produce a charge.

Bandwidth

All node traffic is counted, in both directions — traffic between your nodes, traffic through published services, and file-storage traffic. It is accounted separately so you can see where it goes, and charged as one total: one rate, one pool, one line on the bill. Two rules keep the count fair:

• Node-to-node traffic is billed on one side only (the connection initiator's organization by default), so a byte moving between two of your nodes is never charged twice.
• Service and storage traffic is billed at your node's end only — the far side (the internet, the storage backend) is not double-counted.

Bandwidth is billed to the organization that owned the network a node registered in, so a node that later joins other networks is still counted once. Every measured axis is attributed the same way — bandwidth, storage, compute and, from router 0.4.109, the online-time record behind them — so a node placed in another organization's network never has one part of its usage on one bill and the rest on another.

Every connection in noBGP is relayed through managed infrastructure — that's why it works through any NAT, CGNAT, or firewall, and it's also why bandwidth is a meter at all: a relayed byte costs us money in proportion to how much of it you move.

Storing data is free up to your plan's limit; moving it in or out is bandwidth every time. An organization that keeps 80 GB in a shared drive and pulls all of it ten times over a month pays nothing for the storage and counts 880 GB of bandwidth.

Control-channel traffic is not billed, from router 0.4.103. Keepalives, the once-a-minute metrics push, token refreshes and subscription pushes are what the platform requires to run your fleet — a cadence you did not choose and cannot turn down — so they cost nothing. Through router 0.4.102 they counted as ordinary bandwidth: about 1.5 MB per node per month, which is a rounding error on a small fleet and the whole Free allowance at about 32,000 idle nodes. It is not applied retroactively, so a usage chart shows a small step down at the release and earlier periods keep what they counted.

From router 0.4.130 they are not counted at all. Router 0.4.103 gave them a meter of their own and charged it at nothing; that figure was on no screen and in no invoice, so it is gone rather than kept as an exception. What it buys you is a guarantee rather than a number: there is no longer any unbilled bucket a byte could be pointed at, which is the only way this promise could quietly stop being kept. Nothing about your bill changes — control traffic was already free, and it still is.

An idle node therefore now really can read as zero traffic. What still counts is everything your workload causes: node-to-node sessions, traffic through published services, and file-storage transfers.

⚠ Fixed in router 0.4.130: an old period's bandwidth total read 0 B. The bandwidth figure — the usage screen's bandwidth bar, the projected bill, and the invoice behind them — was summed from the raw per-node measurements, which are kept for the current month plus three; the usage screen offers six months. So looking back past that boundary drew a chart with real gigabytes in it under a total of 0 B and a projected bill of $0.00. All of them now read the rolled-up traffic record, which is kept for 24 months and is the same source the chart already used, so the total, the chart and the invoice agree for every period you can select. Only the reported figure was wrong — nothing was mis-invoiced, because a period is billed while its raw measurements are still there.

A network you deleted mid-period still appears in that period's usage breakdown (router 0.4.73). It is billed for what it moved while it existed — deleting something has never erased the usage it already incurred — but the breakdown used to leave deleted networks out, so the figure you could check was smaller than the figure you paid with nothing on screen to explain the difference. A network with no activity in the period is still not listed once it is deleted.

Nodes and storage stopped being meters in router 0.4.101

Through router 0.4.100 an organization was also billed for active nodes (per node online 24 hours in a period) and for storage (per GB-month on the period peak). Both are now plan limits instead: storage hard-caps on every plan, nodes are unlimited on every plan (Free was capped at 25 until router 0.4.106), and neither can produce an overage charge on any plan. Nothing is billed for them, and nothing reports them to Stripe.

Storage

Storage is a limit, not a meter — 10 GB on Free, 100 GB on Pro, 1 TB on Business — and from router 0.4.101 it is enforced on paid plans too, not only on Free. Reaching it stops new bytes going in; it never produces a charge. See At the storage cap for exactly which operations stop.

The limit is pooled across everything the organization stores: every network's shared drive and every node's own storage area together.

Node storage areas count too, from router 0.4.61 — before that release only the network shares did. An area follows the machine rather than a network, so it counts against the organization that owns the node, alongside that organization's networks in the same pool.

Deleting a network or a node releases its storage — and deprovisioning a node removes it from the directory, so it counts as deleting it here. The bytes themselves are not deleted with it: a deleted node keeps its area and the people who owned it still reach it for 30 days. After that the files are queued for deletion and go about a week later (router 0.4.73). The same clock applies to a deleted network's shared drive — but that drive stops answering the moment the network is deleted, so the window buys you nothing you can use: copy out what you want before you delete the network, not after.

Provisioned compute

A node you provision runs on noBGP's own capacity, and its size is its price. From router 0.4.103 that time is a billed axis in its own right, netted against the compute your plan includes.

Class	Shape	Price	Always-on month
small (default)	0.25 vCPU / 0.5 GiB	$0.02 / hour	$14.60
medium	1 vCPU / 2 GiB	$0.06 / hour	$43.80
large	2 vCPU / 4 GiB	$0.12 / hour	$87.60
xlarge	4 vCPU / 8 GiB	$0.24 / hour	$175.20

The rate is the same on every plan. A larger plan includes more compute, not a cheaper hour. From medium up the rule is $0.06 per vCPU-hour: each class doubles the previous one in size and in price. large and xlarge are new in router 0.4.103, and from router 0.4.144 the capacity behind them is in place — see Compute classes, where the memory in a class is a hard limit and the vCPU figure is a share.

Priced by the hour, billed by the minute, from provision until you deprovision. Each task's running time is rounded up to whole minutes, with a one-minute minimum — so a job that ran for three seconds bills one minute, and elapsed time is never what you are charged for.

The included compute is money, and this page states it in dollars. It is one budget, spendable on any class at any concurrency, at the class rates: $1 buys 50 hours of small, and a medium hour costs three times what a small hour costs, a large hour six times. What is netted is the money, which is why one number covers every class. Concurrency costs nothing extra — eight build workers running for an hour draw exactly what one worker running for eight hours draws.

A provisioned node is still a node, so its traffic counts on the bandwidth meter like any other node's, and its storage area counts against your plan's storage limit. No plan caps how many nodes you may have.

Where the budget went is readable per class, for any billing period — billed hours, cost, and what is left of the allowance — through the compute_usage operation on the REST surface (POST /api/v1/tools/compute_usage with org_id and an optional period as YYYY-MM). Any member of the organization may read it; it is not an Owner-only billing action, because the people running the tasks are the ones who need to see what the tasks cost. See Compute classes for picking a class in the first place.

Tasks provisioned before classes existed show as unpriced

A node provisioned under the old CPU/memory arguments can carry a shape no current class matches. Those rows report their hours with no class and no cost rather than a $0.00 that would read as free work. They bill nothing, which is correct — there was never a rate behind that shape.

Every machine has a deadline

Every machine stops on its own, on every plan, and by default that is 24 hours after it starts (router 0.4.117; Enterprise from 0.4.125). You set it when you provision the machine, and the response comes back with the exact instant it will stop, so you never have to work it out.

You can change it while the machine is running, in either direction, without losing anything — that is what task_deadline_set is for, and it is the only way to keep a machine whose deadline is approaching. Provisioning the same name again is not a renewal while the machine is still up: the name is taken, so you get a second machine as <name>-1 and the first still stops on time.

You can make it longer, and on every plan but Free you can turn it off. Ask for the hours you need, up to your plan's maximum — seven days on Free and no maximum on the paid plans, from router 0.4.155; before it every plan shared one bound of a year. On Pro, Business and Enterprise a machine can be run with no deadline at all — one machine at a time, chosen deliberately, never a default and never for a whole organization. Free keeps its deadline, because the deadline and the included compute are the only two things bounding a Free machine.

⚠ Enterprise takes the same 24-hour default as Business, and this changed. Enterprise machines used to have no deadline at all: the contract is not metered, so no default was applied and the argument was not read. Being unmetered is a statement about the invoice, not about the machine — an Enterprise container nobody remembers still occupies capacity, still holds its name, and still destroys its own disk whenever it eventually stops. It gets the protection every other plan gets, and turns it off per machine when it means to.

The deadline is a reminder, not a limit. It does not reduce your included compute, it costs nothing, and re-starting the machine costs nothing beyond the compute it then uses. It exists because a machine nobody remembers is the one way compute gets expensive.

At the deadline the machine stops the way it stops at any other line — an ordinary offline node, with its identity, labels, grants and storage area intact and its container and local disk gone. Provisioning the same name again brings the node back on a fresh deadline — but only once the machine has stopped, so move the deadline instead when what you want is to keep the machine.

⚠ It is not retroactive. A machine provisioned before router 0.4.117 carries no deadline and runs until you deprovision it.

⚠ Nothing stops an IDLE machine yet. The deadline stops a machine that has run long enough; it cannot tell working from idle. A machine doing nothing still runs until its deadline, or until you stop it. Automatic idle-stop is designed and not built.

When the compute budget runs out

Reaching the line stops running provisioned machines rather than deleting them — the same state a machine reaches at its own deadline, and reached for a different reason. Which line you reach depends on the plan:

• Free is blocked, never billed. Past the included $1 of compute (50 hours of a small machine) and any promotion that is still live, new provisions are refused with a limit error and running provisioned machines are stopped. There is no compute overage on Free and there is no bill.
• On a paid plan compute past the included amount is drawn from your credit balance, at the same class rates, and the machine keeps running for as long as there is credit behind it. ⚠ An empty balance stops it, from router 0.4.128 — once the included compute is used up and the balance is empty, running provisioned machines are stopped, in the same state and by the same sweep as at a deadline, within about ten minutes. Buying credit is what clears it, and the machine comes back by provisioning its name again. Router 0.4.127 left such a machine running, which left a paid organization with nothing left to pay with and no line at all on compute — the bound this page has always described is the balance.
• The spend cap does not stop a machine. It bounds automatic top-ups and nothing else. Through router 0.4.126 it did stop machines, and an organization that had never raised its $0 cap was stopped at the included compute exactly like Free however much credit it held.
• A lapsed payment still stops running compute.
• The deadline you gave the machine stops it whatever your plan and whatever your balance — the one stop that is not about money.
• You can also stop one yourself, from router 0.4.149, with task_stop — the same end state, reached deliberately, and the way to stop spending compute on a machine while keeping the node it ran. See Stopping a machine and keeping the node.

A stopped machine leaves an ordinary offline node, from router 0.4.112. Its compute stops and stops costing anything; its identity, name, labels, role grants and node storage area all stay — and that storage keeps counting against the plan's storage limit, because it is still yours. What does not survive is the container's memory and its local disk: the replacement starts its processes fresh.

Starting it again is re-provisioning. There is no separate resume verb — provision the same name into the same network and the node comes back under the same identity, once the cause is cleared: the payment goes through, you upgrade, or the period rolls over.

There is no separate "suspended" state, from router 0.4.112

Through router 0.4.111 a machine the platform stopped was described as suspended: network_directory carried a suspended_at, and a node that stayed that way was deprovisioned for real after 48 hours on Free, 30 days on Pro or 90 days on Business.

Both are gone. A node has three states — online, offline, deprovisioned — and a stopped machine is simply offline. So there is no marker to look for, no window to beat, and no timer counting down: an offline node lives for as long as you keep it, and what bounds its stored files is the plan's storage limit, which you are already paying against. Nothing was ever reported in the old field, because the enforcement it depended on has not been switched on, so no organization loses an answer it was getting.

⚠ There is no idle timer yet. A provisioned node you are not using keeps running, and keeps drawing your compute budget, until its deadline, until you deprovision it, or until the budget runs out. A machine is stopped for you only for the reasons above and for the deadline it was given.

The spend cap

Every paid organization has a monthly spend cap, set from the billing page. It is the ceiling on what noBGP may charge you without asking: it bounds the credit bought automatically in one period. The flat plan base sits outside it and is the one charge you always pay, and a deliberate credit op=buy by an Owner is never refused by it.

The cap bounds automatic top-ups and nothing else

It refuses no usage, stops no machine and slows no traffic directly, from router 0.4.127. What refuses creation is an empty balance, and what stops a machine is the deadline, Free's compute allowance, a lapsed subscription, or — from router 0.4.128 — that same empty balance.

⚠ Read directly as the whole of that claim, from router 0.4.135. If you have auto-reload armed, the cap sits upstream of every one of those consequences: reach the maximum, and the refills stop being bought, and the balance then falls with nothing to top it up — and an empty balance is what refuses, stops and slows. The cap is named in none of those rules — and for an organization in that position, raising it is nonetheless a way back out of them, because it is what lets the refills resume. Earlier releases stated the first half without the second, which read as this number does not matter; for anyone with a rule armed, it does.

From router 0.4.132 that is the only thing the cap can mean. It held a second meaning where the same usage was invoiced afterwards instead of drawn from a balance, and there the cap was an overage ceiling that refused creation and stopped machines. Usage invoicing is retired, so that regime is gone and with it the refusal it produced: limit_type: "spend_cap" is a refusal the router no longer answers with, on any deployment.

The cap starts at $0, from router 0.4.103. An organization that has never touched it allows no automatic spending at all, so its worst-case bill is exactly the plan fee until an Owner raises the cap or buys credit deliberately. Clearing the cap resets it to that $0 default rather than removing it — there is no way to express "unlimited", which is an Enterprise conversation instead.

Raising it now attempts the refill it has just permitted, from router 0.4.135, instead of leaving you to wait up to a sweep for it — see Saving a setting that permits a refill. Lowering it, or resetting it to the $0 default, attempts nothing: neither can make a refill newly due.

⚠ Moving a running machine's deadline carries no billing check at all. task_deadline_set works whatever your cap and whatever your balance — refusing a new provision costs you a machine you do not have yet, while refusing this one destroys a disk you are still using. It buys nothing while a machine is stopped for some other reason, though: such a machine is stopped whatever its deadline says.

⚠ What slows your traffic is the credit balance, not the cap. Bandwidth is throttled when an included allowance is used up and there is no credit left to draw on — so buying credit clears a throttle without touching the cap, and raising the cap does not by itself keep traffic at full speed once the balance is empty. ⚠ It can now clear one indirectly, from router 0.4.135, and only if you have auto-reload armed: raising the maximum attempts the refill it just permitted, and it is the credit that arrives — not the new number — that lifts the throttle, within about eight minutes. With no rule armed, raising the cap still buys nothing and changes nothing about your speed.

Alerts fire at 80% and 100% of the cap, measured against the automatic refills you have actually bought this period — and, from router 0.4.135, only against a cap above $0, since a maximum that permits no refill cannot be reached by one. They are evaluated on the daily billing sweep, unlike the allowance alerts below, which are re-checked every ten minutes. Raising the cap clears the alerts it invalidated, from router 0.4.109 — the banner stops naming a cap you have already moved, and the next real crossing of that threshold alerts you again instead of being suppressed as a repeat.

⚠ Both of those alerts call it your credit maximum, from router 0.4.129, and name what the number really bounds — automatic top-ups — instead of a block that does not happen. See the emails.

⚠ And from router 0.4.130 they measure it too. The two rungs compare the automatic refills you have actually bought this period against the maximum — a fact, not a trajectory — where through router 0.4.129 they still fired on projected usage overage, which is not what the number bounds. With the $0 default that meant one cent of projected overage sent a you have reached your credit maximum mail to an organization that had no auto-reload rule at all and so had bought no automatic credit. You now reach these two only by actually spending automatic refills up to your maximum, and an organization that never armed auto-reload never sees them.

⚠ What warns you about the balance itself is the allowance pair, which from router 0.4.136 measures against the point that restricts — your included amount plus what your balance buys. The cap alerts have never been about how much money you hold. (Between router 0.4.130 and 0.4.135 that job belonged to a separate pair of credit alerts, now withdrawn.)

At $0, or with no cap set, neither rung fires at all

A maximum of $0 — the default, and what clearing the cap resets it to — is no bound this ladder can alert on, from router 0.4.135. Neither rung fires, and any cap alert already standing against that period is cleared. What warns such an organization instead is the per-axis allowance alerts, which need nothing configured and which from router 0.4.136 are measured against the point that restricts — so on a paid plan they cover the balance running out as well as the allowance.

The reason is that the two rungs measure automatic refills actually bought against the maximum. A maximum of zero buys none, so there is nothing to reach; 80% of zero is not an approach either. Raise the cap above $0 and both of its rungs start working.

⚠ Fixed in router 0.4.135: clearing your cap could send you a you have reached your $0 credit maximum mail. Refills bought earlier under a higher maximum stayed on this period's record, so lowering the cap to zero or clearing it made those refills read as a crossing of a maximum you had just declined — with the remedy in the mail being raise the maximum, and the billing page beside it showing no maximum and no gauge at all. Measured on 6 September 2026: $5.00 refilled under a $20 cap, the cap cleared, and the next daily sweep mailed a $0.00 figure nobody had reached (router#1322).

⚠ Lowering to a positive maximum is still a crossing, and still alerts. Drop a $20 maximum to $3 with $5 already refilled and you are told, correctly: $3 is a bound you chose and hold, the refills really have passed it, and no more will be bought this period. Only at or below zero does none of that survive.

⚠ What refuses a refill is unchanged. An unset or $0 maximum still buys nothing automatically — that is what the default is for. The change is only that a bound which permits nothing can no longer be reached.

It bounded overage only, from router 0.4.92 — and from router 0.4.122 it stopped bounding overage at all. Enforcement used to compare your plan's monthly fee plus overage against the cap, contradicting what the cap has always been described as — so an organization on a $99/mo plan that set a $50 cap was over it before using anything, and was refused new resources and throttled on day one. Every place that read the cap — the creation block, the throttle of the day, and the alerts — was moved onto overage alone. (The throttle has since moved off the cap entirely, onto the credit balance — and from router 0.4.127 so has the creation gate, as below.)

0 is a real value, and it is the default. A cap of zero means nothing charged that you did not ask for: automatic top-ups buy nothing, so the bill is exactly the plan fee until an Owner buys credit deliberately or raises the cap. ⚠ That is now all a $0 cap does, from router 0.4.127 — it no longer refuses creation and no longer stops machines, because an empty balance is what refuses creation and a balance is not a cap. Through router 0.4.91 a zero was read as "no cap set" and silently ignored — the clearest instruction available was the one that did nothing. Through router 0.4.102 an organization that had never set a cap was treated as having none at all; it is now held to $0 like everyone else. ⚠ It is not alerted like everyone else, from router 0.4.135 — neither cap rung fires against a maximum of $0, because nothing bought automatically can reach it. The warning for that organization is the per-axis allowance alerts.

An empty balance is what refuses creation

From router 0.4.127 the creation gate reads your credit balance rather than your spend cap. Creating a node, a network or a service — and registering an agent, and provisioning a machine — is refused only when an included allowance is used up and the credit balance behind it is empty. The refusal is resource_exhausted with limit_type: "credit_empty", and it names both ways out: buy credit, or wait for the period to roll over, when the included allowance comes back.

⚠ Buying credit clears it. That is the point of the change: the cap has bounded automatic refills only since router 0.4.122, so an Owner could hold a large balance and a $0 cap at the same time — and through router 0.4.126 the creation gate still read the cap as an overage ceiling, so that organization was refused every create call and the remedy the product told it to use did not work. The two are unrelated quantities, and the gate now asks the one that can pay.

⚠ An empty balance also stops a machine that is already running, from router 0.4.128 — the same condition, applied to compute you have up as well as to compute you are asking for. Its other published consequence is that bandwidth is slowed. Router 0.4.127 refused the create and left the machine running; that made an empty balance the one exhausted resource with no line on compute at all, so a paid organization with nothing left to pay with kept burning hours indefinitely. See When the compute budget runs out for what a stopped machine keeps.

⚠ The switch under credit op=spending is not read here. An Owner who turned credit spending off has chosen to be slowed rather than blocked, so an organization holding a balance with the switch off still creates resources freely — and, from router 0.4.128, keeps its machines running, because the compute stop asks this same gate. What it asks is whether the organization can pay, not whether it has chosen to.

⚠ Fixed in router 0.4.130: the first minutes of every month refused everything, on every paid plan. An included allowance is deposited for the period and expires with it, so at midnight UTC on the 1st every paid organization's allowance read as gone until the sweep that deposits the new one landed — up to five minutes later. Used up and not written yet are different states and the gate could not tell them apart, so an organization that had used nothing was refused every provision_node, network_create, service_publish and agent registration with limit_type: "credit_empty", right at the moment a monthly job or a scheduled rebuild runs. The gate now asks whether the period's allowance was ever deposited, and a genuinely exhausted allowance is unaffected — its record survives being drawn to nothing. The same window would have slowed traffic and stopped every Free organization's traffic once enforcement is switched on; all three read the one rule now.

Free is untouched by all of this: it has no credit and no card, and it is bounded by its hard caps — past the bandwidth allowance its traffic stops, and past the compute allowance provisioning is refused and running machines are stopped.

Usage credit

Usage past your included allowances is paid from a credit balance your organization buys and holds — bandwidth and compute past the allowance are drawn from that balance at the plan's rate rather than added to your invoice, so a subscription invoice is the flat plan fee and the usage was paid for when the credit was bought.

⚠ From router 0.4.132 it is the only way usage past an allowance is ever paid for. A router could also run the other way until this release, invoicing the same usage afterwards through metered subscription items; noBGP does not bill for usage, and that mechanism — the metered prices, the usage push to Stripe, and the overage ceiling the spend cap was on that path — is retired rather than switched off. A plan subscription, then credit you buy or refill automatically, is the whole of it. The pricing model is unchanged: the same rates, the same included amounts, the same decimal gigabyte.

POST /api/v1/tools/credit with org_id on the REST surface, Owner only like every other billing action. The operation is chosen with op and defaults to status, which changes nothing. Every operation returns the whole position afterwards, so a change never needs a second call to see what it did.

You do not have to poll it to know the balance is running low. The allowance alerts email the organization's Owners at 80% and 100% of what it may actually use — which on a paid plan holding credit counts the balance, so one of them arrives before the money runs out and the other when it has. Router 0.4.136 measures them that way; between router 0.4.130 and 0.4.135 the same two warnings came as a separate pair.

credit_billed answers true and nothing else, from router 0.4.132. The field arrived in router 0.4.118 to say which of the two regimes a deployment ran, and it read false where the same usage was invoiced instead — there, the balance was spent by nothing and op=buy was refused because there would have been nothing for the money to pay for. With usage invoicing retired there is no second regime for it to describe, so it is a constant: it stays on the wire so an existing client keeps reading an answer, and nothing new should branch on it.

⚠ Earlier notes here and in the changelog say overage is invoiced on noBGP's own routers. That described the regime those releases ran under; it stopped being true of your usage in router 0.4.123, and the mechanism itself is gone from router 0.4.132.

A rise in your included allowance gives back the credit it stranded, from router 0.4.130. Credit is drawn against the allowance in force at the moment the usage is measured, so if the allowance then rises mid-period — you upgrade your plan, or an allowance we granted your organization is widened — the balance had already paid for traffic and compute the larger allowance now covers. The rule is that money may only ever have paid for usage the period's allowance cannot cover, checked on every sweep: the difference comes back to the balance, spent_this_period_cents falls by it, and the usage goes back to being netted against the allowance. It runs in one direction only — an allowance that falls never takes money back — and it needs no action from you. ⚠ Only a live grant is refunded: credit that has already expired stays spent.

⚠ A purchase completes from router 0.4.123. Through router 0.4.122 no credit purchase ever completed on any deployment, manual or automatic: the router reserved the amount against the period maximum and then could not read the reservation back, so the card was never reached and the reservation went on counting in purchased_this_period_cents — and, for an automatic one, auto_refilled_this_period_cents — for the rest of the period. An organization left holding one also had its auto-reload skipped, because the sweep steps over an organization with a purchase in flight. Nothing was ever charged for one, and the stranded reservations have been released.

The allowance that expires first is spent first

On one meter — bandwidth, or compute — the allowance that expires soonest is spent first. That covers this month's included amount, and any allowance noBGP has granted your organization. The date decides the order, not the kind of allowance:

• Your monthly included amount expires at the end of the month it is for. So it is spent before anything that lasts longer.
• A granted allowance that lasts longer waits behind it, and is what you draw on once the month's own amount is used up.
• Two that expire at the same instant cost you nothing either way. Neither can outlive the other, so whichever is drawn first, you can spend the same total.

⚠ Your credit balance comes after all of it. Credit pays for usage past the period's allowance. So every allowance on a meter is spent before any money, whatever the dates say. Inside the balance the date rule applies again: credit noBGP granted you expires and is spent first, and credit you bought does not expire and is spent last.

⚠ No allowance is stranded by waiting its turn. The nearest deadline is always taken first, so an allowance cannot expire unused while a longer-lived one is spent ahead of it. Granted credit is the one exception, because it sits behind every allowance. And no order extends a deadline: an allowance you had no usage for is gone on its own expiry date, wherever it sat in the order.

What a multi-month allowance counts as included

The included amount a month shows is what your allowances hold for that month — live since 2 October 2026 (UTC). It matters for a granted allowance that outlives one month: the launch promotion lasts 60 days, so it can cover three calendar months, and each of those months used to count the whole of it.

Three things it corrects:

• What an earlier month already drew is subtracted. Before, a month counted the whole allowance, so the panel showed more left than the balance held. The stop reads the balance, so such an organization was stopped before its meter showed zero.
• In the month an allowance expires, once it has expired, that month counts only what was drawn from it, not its whole amount.
• A revoked allowance keeps what was drawn from it. That usage stays included in the month it happened in, instead of turning into overage, and earlier months do not change.

A month that has closed reads the same whenever you read it again. Its usage is final, and an allowance that outlived it gives it what it held at that month's start, which nothing later moves.

What status reports

Every amount on this surface is in cents, in and out.

Field	What it means
credit_billed	Whether this deployment pays usage past the allowance from the balance at all. Always true from router 0.4.132 — a balance is the only way it is ever paid for. Kept so an existing client keeps reading an answer; do not branch on it
credit_enabled	Whether your organization allows its balance to be spent. true by default; changed with op=spending
balance_cents	Credit available to spend. null is not zero — it means the organization draws on no balance at all, which is the unmetered Enterprise tier; zero means the balance is empty
spent_this_period_cents	What the balance has paid for so far this period, across every axis. Read it beside the balance: "$12 left" says nothing without knowing what the month opened with
purchased_this_period_cents	Credit already bought or reserved this period, automatic and manual together — the figure to report. ⚠ It is not what spend_cap_cents bounds, so never derive the refill headroom from it
auto_refilled_this_period_cents	Credit bought automatically this period, counting purchases still in flight, from router 0.4.122. This is the figure the maximum is measured against: the refill headroom is spend_cap_cents minus this
pending_purchase_cents	Credit bought this period whose charge has not settled yet, automatic and manual together, from router 0.4.127. Zero means nothing is in flight. ⚠ It is already inside purchased_this_period_cents and — for the automatic part — inside auto_refilled_this_period_cents; never add it to either
oldest_pending_purchase_at	When the oldest unsettled purchase was started, RFC3339 UTC, or null when nothing is pending (router 0.4.127). Subtract it from your own clock: minutes are ordinary, hours mean the purchase needs a person to settle it
spend_cap_cents	The most credit that may be bought automatically in one period. null means the $0 default applies, so auto-reload buys nothing until an Owner raises it with set_spend_cap. ⚠ From router 0.4.122 it bounds automatic refills only — a manual op=buy is never refused by it — and it never bounds the flat plan fee
auto_reload_trigger_cents / auto_reload_reload_cents	The standing top-up rule — buy this much whenever the balance falls below that. Both null means auto-reload is off, which is where every organization starts
period / period_end	The calendar month these figures cover, and the instant it resets

⚠ credit_billed and credit_enabled are two different questions, and only the second one still varies. The balance used to be spent only when both were true — the deployment had to draw on a balance at all, and your organization had to allow its own to be spent. With credit_billed pinned true from router 0.4.132, credit_enabled is the whole answer: it is your organization's own switch, it defaults to true, and it is what op=spending changes.

⚠ Money in flight is a normal state and is usually brief. pending_purchase_cents is what separates your money is on its way from your money has stopped — a balance of $0 beside purchased_this_period_cents: 2000 reads identically whether the charge is one second or four hours old, and until router 0.4.127 neither figure could be unfolded. A purchase that is still pending after a few minutes is one to raise with support; op=purchases is where you see which one it is.

The record that your card was charged

op=purchases lists this period's purchase attempts, newest first, from router 0.4.127. It returns the same position status does and adds a purchases array — and it is the only customer-visible record that a card was charged, because a credit purchase is charged straight to the payment method and therefore appears on no noBGP invoice. It is also the only place a failed purchase is visible at all: before this release a declined card simply meant the balance did not rise, with nothing anywhere saying why.

Field	What it means
id	This purchase's id. It is the same id the charge carries at Stripe, so you and support can name one purchase to each other
amount_cents	What the purchase attempted to buy. On a succeeded row, what the card was charged
kind	manual for a purchase an Owner asked for, auto_reload for one the standing rule made
status	succeeded — charged and credited. failed — nothing was charged. pending — still in flight; a row that stays pending is one to raise with support
created_at / settled_at	When it started, and when it succeeded or failed. settled_at is null while it is pending
failure	Why a failed purchase did not complete, in one sentence you can act on — the card was declined, the card wants an extra confirmation step this off-session charge cannot perform, or a generic try again. null on every row that is not failed, and never null on one that is

• period (YYYY-MM) is accepted on this operation and refused on every other one. Omit it for the current period, which is what a billing page shows. ⚠ It moves the whole payload to that month — the purchases, what the period spent and bought, and period_end — so the figures beside the list always describe the same month as the list. A month that is not zero-padded YYYY-MM is refused with invalid_args rather than answered with an empty list.
• At most 500 rows, newest kept. That is a stated cap and not a page: one period usually holds a handful of rows, and the exception is a dead card — auto-reload with a card that keeps declining writes one failed row per attempt. Through router 0.4.132 that was an attempt every fifteen minutes, about 2,900 in a month; from router 0.4.133 the rule backs off to about one a day.
• ⚠ purchases is null on every other operation, and [] is a different answer. null means the call did not ask; [] means the period holds none.

Changing it

• op=spending turns the balance on or off as a way to pay, with enabled. It is required: a call that omits it is refused rather than defaulted, because either default would silently change how you pay. enabled: false keeps the balance and spends none of it — at the allowance traffic is slowed, exactly as an empty balance would leave it. Nothing is refunded or expired either way, and turning it back on spends the same balance. ⚠ It slows traffic; it does not stop machines or block creation. From router 0.4.127 running provisioned machines keep running, and the creation gate reads the balance rather than this switch — an organization that holds credit and has chosen to be slowed can still pay, so it is not also blocked.

• op=auto_reload sets the standing rule with trigger_cents and reload_cents — both or neither. Sending both as null switches it off. The rule fires when the balance falls strictly below trigger_cents, so from router 0.4.122 the trigger must be at least 1 cent: the balance stops at zero, so a trigger of 0 would be a rule that saves and can never fire, and it is now refused with invalid_args. Spell refill once the balance is empty as a trigger of 1. reload_cents must be at least 500 cents ($5) from router 0.4.136 — see the $5 floor — and every automatic purchase is bounded by the period maximum: one that does not fit is reduced to whatever is left rather than skipped, down to that same $5, so the budget is spent instead of the remainder being stranded.

  ⚠ Saving a rule the maximum leaves nothing to buy is allowed, and now says so. The two settings are independent and either order of saving them is legitimate, so a rule armed while this period's maximum has less than $5 of room left is written — and the reply names the room and says the rule will buy nothing until you raise the maximum with set_spend_cap. Setting the maximum from the other side reports the same thing when a rule is already armed. Through router 0.4.135 both saves were silent, and status reported the rule as armed, which it was: armed and unable to fire.

  ⚠ A declined refill now holds the rule off before it tries again, from router 0.4.133 — see when the card keeps declining. Through router 0.4.132 nothing held it: a card that had stopped working was presented every fifteen minutes for as long as it stayed dead.

  ⚠ Arming the rule tries it at once, from router 0.4.135 — see above. A rule armed against a balance already below its trigger used to sit for up to a sweep doing nothing, which reads exactly like a rule that failed to save.

  ⚠ The rule lasts as long as the subscription renews. From router 0.4.177 cancelling renewal clears it immediately, even though the plan stays paid until the period ends — what a cancellation clears. Arming it again during that remaining period is a new authorization and is allowed.

• op=buy charges the payment method on file once, now, for amount_cents — at least 50 cents, because the card network refuses less. ⚠ From router 0.4.122 it is not bounded by spend_cap_cents: the maximum is the ceiling on spending nobody authorized one purchase at a time, and an Owner buying deliberately is the opposite of that — so an organization sitting at its maximum can still buy the credit that clears its throttle. Through router 0.4.121 the same call was refused with this purchase would pass the period maximum, which left an organization throttled and unable to buy its way out. Its remaining refusals are separate because their remedies are: no saved payment method (subscribe, or add one from Account → Billing), an organization that has never subscribed and so has no card to charge, and a declined card. ⚠ The fourth one is gone from router 0.4.132 — a purchase used to be refused on a deployment that invoiced usage instead of drawing a balance, and there is no such deployment now.

  ⚠ The method it charges is the one the billing summary shows, from router 0.4.120 — from router 0.4.130 the customer default first, then the subscription's method, then the only method attached. Through router 0.4.119 the purchase read the customer default alone, so it was refused as having no saved card for an organization whose subscription was charging that very card every month; through router 0.4.129 it read the subscription first, so it charged the card you had replaced rather than the one you had just entered.

Stripe emails a receipt for a credit purchase, from router 0.4.127 — to the organization's first Owner, for a deliberate purchase and for an automatic refill alike. Through router 0.4.126 it sent nothing at all: money left a card and no document anywhere said when or how much.

⚠ A receipt is not an invoice, and a credit purchase still adds no row to the invoice list the billing operation returns — that list is subscription invoices only. Credit is charged straight to the payment method rather than invoiced, because an invoice implies terms, a due date and dunning, none of which apply to a card charge that has already settled. The charge reads as noBGP usage credit on the statement, and credit op=purchases is the record inside noBGP.

⚠ The receipt is best-effort and never blocks a purchase. If the Owner's profile holds an address Stripe would reject — a display form like Alice <a@b.com>, a stray space, anything that is not a plain address — the purchase goes through with no receipt address rather than failing. It has to work that way: an unusable address would otherwise fail the whole charge, and with auto-reload on that is a balance that never refills and a slowdown nobody can explain, over a courtesy email.

Free organizations have no credit and no card, and an Enterprise organization is invoiced in arrears and reports a null balance.

The smallest automatic refill is $5

From router 0.4.136 an automatic refill is at least $5, and that floor is ours rather than the card network's. It binds two things: the smallest reload_cents a rule may be saved with, and the smallest remainder the period maximum's truncation will buy.

The reason is the card fee. On standard card pricing (2.9% + 30¢) the fee on a 50¢ charge is about 63% of it — we grant 50¢ of credit and receive about 19¢ — against about 9% at $5. The old floor was Stripe's API minimum, which says what a card network will accept and never said anything about what is worth charging.

• A purchase you make yourself is unchanged at 50 cents. credit op=buy is bounded by the card network alone, not by this floor and not by your maximum, so buying a small amount deliberately is still available — including as the way out of a slowdown.
• ⚠ A rule you already had below $5 keeps buying the amount you typed. The floor binds a save and a truncation; it does not rewrite a number you chose, and silently charging more than you asked for would be worse than the fee. You cannot re-save such a rule below $5, so the exception only shrinks.
• ⚠ Up to $4.99 of a period maximum can now go unspent, where the truncation used to spend down to 50¢. Nothing about keeping your service running changes: a manual purchase is never bounded by the maximum.
• ⚠ A maximum with less than $5 of room left is a maximum an armed rule cannot buy against — including the $0 default, which is where every organization arming auto-reload for the first time starts. Both credit op=auto_reload and set_spend_cap say so in the reply when you save; see op=auto_reload above.

Saving a setting that permits a refill tries it at once

From router 0.4.135, two settings changes attempt the refill they have just permitted instead of waiting for the next sweep: raising your spend cap with set_spend_cap, and arming the standing rule with credit op=auto_reload.

The balance is checked against your trigger every fifteen minutes, so before this release the one act whose entire purpose is to allow more automatic buying bought nothing at the moment you pressed Save. On an organization whose traffic was already slowed that was up to fifteen minutes waiting for the check, and then up to eight more for the slowdown to lapse once the credit landed — about twenty-three minutes of nothing visibly happening, which now becomes about eight. The remaining eight are the slowdown's own clock and are unchanged: what moved is when the money arrives, not how quickly your fleet notices.

⚠ It changes when, never whether. The attempt runs the same decision the sweep runs, with every guard intact: the rule must be armed, the balance must be below the trigger, the amount is still bounded by the period maximum and still truncated to what is left of it, and a declined card is still held off — so pressing Save repeatedly is not a way to keep presenting a card that is not working. Where the sweep would have bought nothing, this buys nothing.

⚠ And a save that attempted a charge holds the next save-triggered attempt off for about five minutes, from router 0.4.140. The guards above are what ordinarily stop a repeated Save presenting a card that is not working, and they are read from your organization's record of recent refills — so on the rare occasion that record cannot be read, there is no back-off to apply and each press would reach the card again. It bounds repeated saves; it is not a promise of one charge per five minutes. The ordinary fifteen-minute check still runs in the meantime, which is the wait this feature removes and the floor it falls back to.

⚠ Only an attempt starts that wait. A save that bought nothing — no rule armed, nothing due, the maximum already spent, the card held off — leaves it alone, so saving your maximum and your rule together is still evaluated against both. It is also a second line of defence rather than a replacement for the back-off: the decline schedule is what bounds a dead card across the whole platform, and this bounds the window in which that schedule cannot be read.

⚠ Only the two changes that can newly make a refill due. Lowering your cap or resetting it to the $0 default removes permission to spend and fires nothing; switching auto-reload off fires nothing. Saving an armed rule that changes nothing does fire, and buys nothing, because the guards above already answer it.

⚠ It happens behind the reply, so the reply says nothing about it. The setting is written and confirmed whatever the card then does — a decline must never fail a cap change you asked for — so read the outcome from your balance, or from credit op=purchases, which is where a failed attempt and its reason appear. Give it a few seconds: the attempt waits briefly first, so that saving a new maximum and a new rule together is evaluated against both rather than against the old amount.

⚠ Nothing is bought twice. The attempt and the fifteen-minute sweep take the same lock, so whichever gets there first is the only one that charges; if the sweep is already running for you, your save simply leaves the decision to it — which is the wait you had before this release, and the floor this sits on.

When the card keeps declining

From router 0.4.133 a declined automatic refill holds the rule off, and consecutive declines double the wait. The balance is checked against your trigger every fifteen minutes, and until this release that was also how often a dead card was presented: a card that had stopped working declined about 2,900 times a month, wrote one failed row on op=purchases each time, and none of it moved the balance or the period maximum, because a failed purchase charges nothing and reserves nothing.

The hold runs from the decline, and the retry lands on the first sweep after it expires:

Consecutive declines	Hold	Next attempt, about
1	15 min	30 min after the decline
2	30 min	45 min
3	1 h	1 h 15
4	2 h	2 h 15
5	4 h	4 h 15
6	8 h	8 h 15
7	16 h	16 h 15
8 or more	24 h	24 h 15

⚠ One attempt a day is the floor, and it is deliberate: a card that starts working again is retried within a day with nothing for you to do, while one that stays dead costs a decline a day rather than 96. The hold is counted from the newest decline, so a run of eight spread over three days holds the rule for a day after the last of them, not for eight days.

A purchase that succeeds ends the run at once — including a manual op=buy, which is the remedy a failed-payment mail sends you to. The declines are counted back from your newest purchase and stop at the first one that is not failed, so a single successful charge puts the rule straight back on its ordinary fifteen-minute schedule; there is nothing to reset by hand. A failed manual purchase is not the rule failing and never lengthens the hold.

⚠ The rule is held, not switched off. Nothing about trigger_cents or reload_cents changes, no setting is cleared, and status reports the same standing rule throughout — what a hold changes is only how soon the next attempt is made. Fixing the card in Account → Billing and waiting is enough.

⚠ A hold does not stop your balance running out. While it is running the balance still falls, so bandwidth past the allowance is still slowed and an empty balance still refuses creation and stops machines. Buying credit yourself is the fast way back, and it clears the hold as a side effect.

You are told when an automatic refill is refused

From router 0.4.136 a refused automatic refill emails the organization's Owners. Through router 0.4.135 it told nobody: a declined card put the rule into the back-off above, the balance drained, and the first signal was whatever the empty balance then did — days later, from a mail that said buy credit and never mentioned that a card had been refused.

⚠ The failed-payment mail could not cover this and never will. That one fires from your subscription's invoices; a credit purchase is a direct card charge on no invoice, so a refused refill reaches none of that machinery. The two are different money: one is the plan you subscribed to, the other is the balance keeping your usage running.

Two causes are named, because their remedies differ:

Cause	What the mail says
The card was declined	Your refill rule tried to buy credit and the card refused it. Update the payment method from Account → Billing; the rule is retried on an increasing schedule, at most once a day while the card keeps refusing. You can also buy credit yourself at any time, which your maximum never bounds
There is no card to charge	Automatic refills are on and no payment method is saved, so nothing can be bought. Add a card, or switch automatic refills off to stop the messages

• Either mail says the balance is no longer being topped up automatically, and then names what happens if it does run out — the refusal, the compute stop and the slowdown — under whichever of them is actually being applied, and nothing where none is.
• Once per period per cause, not once per attempt. The back-off doubles to a day, so a per-attempt mail would put eight messages in front of you on the first day of a dead card — and the remedy does not change between attempts. A change of cause is a new mail: a card that starts declining and is then removed altogether is two problems with two remedies.
• A successful automatic refill re-arms it, so a second failure later in the same period is told rather than swallowed.
• ⚠ The specific decline reason stays in credit op=purchases. The mail says what happened and what to do; the row carries the failure sentence for that attempt.
• ⚠ Only a refused card sends it. A purchase that failed on our side — above all one where the charge settled and something after it did not — never tells you your card was declined, because asking you to fix a payment method that just worked would be a wrong statement about your money on top of the money being wrong.
• ⚠ Reaching your credit maximum is not one of these causes. That has its own pair of alerts with its own remedy, and saying it twice would be two mails about one state.

Cancelling clears your standing instructions about money

From router 0.4.127, cancelling a subscription erases the organization's auto-reload rule and its spend cap along with its plan. An auto-refill rule is a standing authorization to charge a card without asking, not a preference — kept across a cancellation it re-armed the moment the organization subscribed again, with nothing in checkout mentioning it, so the first notice would have been the charge.

The numbers are written to the organization's audit log so you can read them back and enter them again deliberately: billing.credit_auto_reload_cleared carries the trigger and the amount, billing.spend_cap_cleared carries the maximum. They survive as history, which nothing can act on, rather than as live settings a re-subscription could re-arm. Nothing is written when there was nothing set.

⚠ Fixed in router 0.4.136: that record could be lost, and on noBGP's own router it always was. The clear and the audit line were two separate writes, so anything between them — an error, a retry, a dropped connection — destroyed a standing authorization to charge a card and left nothing saying what it had been. Measured 7 September 2026 against seven cancellations since the behaviour shipped in router 0.4.127: zero rows of either kind, on an organization demonstrably cleared. They are now written in the same transaction as the clear itself, so the setting cannot vanish without its record. Cancellations before router 0.4.136 have no line to read back — ask support if you need one.

⚠ This is cancellation only, not a failed payment. A subscription that lapses and is restored keeps both settings; a failed payment clears neither.

From router 0.4.177 the auto-reload rule is cleared the moment you cancel renewal, not when the period ends. Cancelling turns off automatic credit purchases at once, while the paid plan itself runs to the end of the period you have paid for — which is what noBGP's Terms of Use say, and through router 0.4.176 the rule went on buying credit for the rest of that period. The clear is recorded exactly as the end-of-period one is, with billing.credit_auto_reload_cleared carrying the trigger and the amount.

• Your credit maximum is not cleared at that point, and the difference is deliberate: a maximum is a limit on automatic purchases, not an authorization to make one, and an Owner who arms a rule again for the rest of the period needs it. It is still cleared with the plan when the subscription actually ends.
• You can arm a new rule for the remaining period, and cancelling does not then undo it: a rule saved after the cancellation is left alone.
• Undoing the cancellation does not bring the rule back. Renewal resumes; the standing authorization to charge your card does not, so arm it again if you want it.
• Credit you have already bought is untouched, and buying more yourself works throughout — what stops is the automatic purchase.

Allowance alerts

Separately from the spend cap, an alert fires at 80% and 100% of what your organization may use on each axis this period — bandwidth, storage and, from router 0.4.103, compute — once per threshold per period, and shows as a banner in the web app. There is a node row too, and from router 0.4.106 nothing can trip it: no plan caps how many devices you may have.

Each alert names what reaching that particular limit actually does, because the three are different mechanisms: bandwidth stops on Free and is drawn from the credit balance on a paid plan, storage refuses new uploads on every plan, and compute stops running machines. The compute row matters more than the others, since hitting 100% there stops work already running — so its 80% alert is the warning that arrives before the work stops rather than with it.

On a paid plan still on the default $0 spend cap, these are the only early warning you get — the cap's own 80% alert cannot fire against a cap of zero, so the per-axis 80% here is what tells you your fleet is about to meet a limit. On a paid plan holding no credit to spend, that limit is the slowdown rather than a bill.

The two rungs measure the point that restricts, not the included amount

From router 0.4.136 they are measured against the point at which something is actually refused, stopped or slowed — and on a paid plan holding credit it may spend, that is not the included amount. Passing the allowance there does nothing: the usage simply starts drawing the balance. Through router 0.4.135 both rungs fired at the allowance anyway, so a funded organization was told twice about a limit it had not reached, on a channel whose whole value is that its warnings are real.

What the rungs measure against is therefore a capacity: the included amount, plus what the balance buys at your plan's rate. Four things follow.

• Where money cannot extend the axis, nothing changed. Free is hard-capped, so its allowance is the whole contract; storage has no rate on any plan, so credit cannot buy it; and a paid organization that has switched credit spending off, or whose balance is empty, is bounded by the allowance as well. On every one of those the two rungs are exactly the numbers they have always been.
• The balance is one pool across the axes, so compute drawing it shrinks what bandwidth may reach with no bandwidth usage at all — you can cross 80% on an axis you have not touched. That is honest rather than a glitch, and it is why the mail states what the number is made of instead of only the number.
• The capacity extends from what you have already used, once that passes the included amount, because every unit past the allowance was paid for out of the balance as it was measured. Drawing the balance down therefore does not move the number — one unit added to your usage is one unit taken off what the money buys.
• Buying credit does move it, and re-warns you against the new number. That is the one change worth a second mail, so it is not swallowed as a repeat of the alert you already had. Small movements are ignored: the figure the reminder is keyed on is rounded to two significant figures, so the two reads behind it drifting by a few minutes of traffic cannot mail you every sweep.

⚠ The rung fires at the exact capacity; only the reminder is rounded. The 100% edge is where the refusal and the slowdown are, not a rounded neighbour of it.

The alert is emailed too, and it names the date the allowance comes back

Every alert is also emailed to the organization's Owners — the allowance pair, the spend cap pair, the refused automatic refill from router 0.4.136, and the subscription lifecycle ones (a failed payment, a lapsed subscription, and its restoration). Owners rather than everyone: each one asks for something only an Owner can do. The mail says what reaching that particular limit does, in the tense it is actually happening in — while enforcement is off it says the limit is exceeded and not yet enforced, and what enforcement will do, rather than claiming a consequence nobody is applying. (A credit balance pair was emailed as well between router 0.4.130 and 0.4.135; router 0.4.136 folds it into the allowance pair.)

⚠ On a credit-extended axis the mail states the whole capacity, from router 0.4.136 — the total you may use this period, the part of it your plan includes, and how much credit is left — because a number that is neither your allowance nor your balance is unreadable without saying what it is made of. It offers buying credit, or arming automatic refills, as the way to add to it, and claims an interruption only where one is actually being applied.

⚠ And the Free mail finally names an action. Free's bandwidth consequence has been a stop since router 0.4.106, which makes its 80% mail the last warning before traffic ends — and through router 0.4.135 it named no remedy at all. It now says plainly that a paid plan raises the included amount and that the allowance itself cannot be raised on Free.

⚠ On a paid plan the mail names the creation refusal as well as the slowdown, from router 0.4.127, and it names both conditions rather than one: new nodes, networks and services are refused once the included amount is used up and the credit balance is empty. The two consequences are governed separately — the refusal applies today, the slowdown waits for enforcement — so held together in one sentence the 80% mail told a customer nothing was refused while their provision_node was being refused as it arrived. From router 0.4.128 it names the compute stop as the third, under whichever conditions are live at the time: the mail says machines you have provisioned are stopped only where that is being applied, and otherwise says it is not yet enforced.

⚠ The two spend-cap mails name the credit maximum, from router 0.4.129. Both rungs used to describe the retired mechanism — a ceiling on usage above your included amounts, with creation refused at it — which is not what the number does where usage is paid from a balance. Both now say that the maximum bounds automatic credit refills and nothing else, and that credit you buy yourself is never bounded by it. The 100% mail adds what that bound is — while the maximum is reached, no automatic refill is bought this period — and then offers both remedies, raising the maximum and buying credit, and names the purchase as the one the maximum cannot bound. Anything that follows from an empty balance is named separately, as following from the balance.

⚠ The 100% mail no longer says the maximum refuses, stops and slows nothing by itself, from router 0.4.135 — it says nothing directly, and then names the hop. Everyone who receives that mail has a refill rule armed and has bought refills up to their maximum, so for every one of them the chain is real: the maximum is reached, the refill is held back, and a balance that relies on that refill now falls with nothing to top it up. Telling someone the number they have just reached slows nothing, one sentence before telling them what happens when their balance runs out, left them with no reason to connect the two.

⚠ The subscription is active again mail no longer promises to restore what was never withdrawn, from router 0.4.129. It said back to full speed whether or not anything had been slowed — and the slowdown waits on enforcement, so for a real customer it described the end of three things that had never started. It now names what a lapse actually withdrew, and where that was nothing, it says so. Its caveat names the limit that can still refuse creation afterwards: an included allowance used up and an empty balance.

⚠ Fixed in router 0.4.135: only the first of each subscription mail in a calendar month was ever sent. The three lifecycle mails — a failed payment, a lapse, a restoration — were recorded once per month per kind, alongside the allowance and cap alerts, which is the right rule for a threshold you can only cross once and the wrong one for an event that can happen twice. So a second failed charge in the same month was silent, and so was a second restoration: measured on 6 September 2026, an organization whose payment went through already held a subscription is active again record from 4 September, and no mail went for the recovery it had just made — with nothing on the record to say one was owed.

They are now recorded per event, keyed on the invoice each transition is about, so each occurrence is its own mail and the history is kept. Two things stay true through the change:

• Stripe retrying the same failing invoice is still one mail. A failed charge is retried several times over the dunning window and every retry carries the same invoice, so you are told once. A different invoice failing is a new event and a new mail.
• Going further into arrears is still one lapse. A subscription walks past due → unpaid → cancelled; the mail goes on the way in, not at each step.

⚠ Fixed in router 0.4.138: two billing events arriving for one organization at the same time could lose the second one's mail. Each mail was decided from the subscription status as it stood when its event was picked up, rather than from the status the write it then made had just replaced — so where two Stripe deliveries overlapped, the later one tested against a value the earlier had already moved past, and the transition it should have announced was never seen. The case it was found on is the one that matters most: a card recovered, and the subscription is active again mail did not go. Each mail is now decided from what its own write replaced, so two events for one organization can no longer both read the same starting point.

⚠ And a plan change made while a payment is outstanding does not read as a second failed charge. Switching plan while past due invoices the difference at once, which is a new invoice and not a failed one — and only a charge that genuinely declined sends you the we could not process your payment mail again while you are already past due.

⚠ An allowance mail no longer claims that nothing at all is refused. With enforcement off it speaks about its own axis — this allowance is not enforced yet — and names separately that limits which come from billing can still refuse new nodes, networks and services. On a paid plan those are two different questions: the storage allowance being unenforced says nothing about whether that organization's provision_node is being refused on its credit balance.

From router 0.4.114 it also names the date, on both the allowance mails and the spend-cap one: "until 1 September 2026, when the period resets" instead of "until the next billing period", which is true and tells you nothing unless you already know that periods are calendar months and that yours starts on the 1st. The date is best-effort — where it cannot be resolved the mail still goes out with the older phrasing, because a vaguer sentence beats a gap in one.

These reach every plan, including Free, from router 0.4.91. Before that release they were evaluated only for organizations the metered-billing run covers — which by definition excludes Free, since Free has no overage to meter — so the plan whose allowance is enforced by throttling was the one plan that could never be warned it was approaching it. No Free organization had ever received one, including organizations already over the allowance and being throttled for it.

An alert clears when the limit it named moves, from router 0.4.109. Each threshold fires once per period, and until this release the record of it stayed for the rest of that period whatever happened next — so an allowance that moved underneath it left a banner naming a limit that no longer existed (upgrading the plan, raising the spend cap, or a limit changing in the catalogue), and, worse, the next genuine crossing of that same threshold was swallowed as a duplicate, email included. Every sweep now re-states what is actually true: the threshold that holds fires, and the ones above it are cleared. A less severe alert is kept while a more severe one holds — you were already told about 80% on the way past it, so falling back into that band after a limit is raised does not re-alert you.

Every organization's usage is now re-checked against its allowances every 10 minutes, so the warning arrives ahead of enforcement rather than in the same breath as it — enforcement itself is re-evaluated every two minutes. On a fast link an allowance is minutes of traffic and no warning can lead a burst that size; what this buys is notice for the ordinary organization creeping up on its allowance over a month. That gap does more work since router 0.4.106: what follows the Free bandwidth alert is a stop, not a slowdown.

Credit balance alerts, and what replaced them

Router 0.4.130 added two alerts about the money you hold — balance running out and balance empty — and router 0.4.136 withdraws both. Nothing about your balance goes unwatched: the allowance pair now measures against the point that restricts, and on a paid plan holding credit that point is the balance running out. The two events are the same two events; what changes is that they arrive named by the axis that ran out — bandwidth, or compute — which an organization-level mail about money could never say.

The retired alert	What tells you now
Balance empty	The 100% allowance rung on the axis. It is the same condition — an included amount used up and the balance empty, exactly what refuses creation — so the mail and the refusal still cannot disagree
Balance running out	The 80% rung on the axis, plus the sentence in that mail naming what happens when the capacity is used up

⚠ The running-out projection survives as a sentence rather than as its own trigger, and it loses a false alarm with the change. It could not see an automatic refill rule, so it warned organizations whose rule already covered the gap.

⚠ Rows already standing are cleared rather than left. A banner from one of these alerts describes a condition nothing re-evaluates any more, so every sweep withdraws them until none is left; an organization that leaves the paid tier — cancelling, or moving to Free — has them cleared with everything else.

They were never wrong; they were the allowance rungs measured against the other half. Through router 0.4.135 the allowance pair fired at the included amount, which restricts nobody who holds credit, and this pair fired at the balance, which is where the restriction actually is. One basis answers both, so there is one mail per axis instead of two mails about one event.

When bandwidth is limited

Your nodes are never disconnected. Whatever the reason, a node stays online, stays in the directory and keeps its connection to the router — what changes is what its data traffic may do. There are two regimes, and from router 0.4.106 they are different things rather than two settings of one:

Situation	Plan	What happens to data traffic
Over the included bandwidth allowance	Free	Stopped until the period rolls over or the organization moves to a paid plan — see below
Included allowance used up and the credit balance empty — or credit spending switched off	Paid	Throttled to 1 Mbit/s per node, in both directions
Payment lapsed	Paid	Throttled to 1 Mbit/s per node, in both directions

On a paid plan traffic is never stopped. Usage above the included allowance is drawn from your credit balance at the plan's rate, and when that balance runs out — or a subscription lapses — the fleet is slowed rather than cut off: DNS, a slow shell and the dashboard keep working, and every node has its own 1 Mbit/s rather than sharing one. Full speed returns automatically once the trigger clears — the period rolls over, credit is bought, or the payment goes through. ⚠ The spend cap is not one of the triggers: it bounds automatic top-ups, and raising it does not by itself return a slowed fleet to full speed. Buying credit does.

On Free, passing the allowance stops the traffic

From router 0.4.106 a Free organization past its 50 GB stops moving data rather than being slowed to 1 Mbit/s. Through router 0.4.105 it was throttled the way a paid organization is when it has nothing left to pay with, which was the wrong shape for a plan with no bill behind it — a network that is indefinitely slow is not a limit, it is a worse product. A stop is legible, it clears by itself when the period rolls over, and the allowance alerts at 80% and 100% are what arrive before it.

From router 0.4.130 the stop asks the same question the paid slowdown asks — is anything left of what this period granted you? — rather than comparing the period's total against today's plan row. Three things follow, and all three are small:

• The boundary is exact. The two figures used to be rounded to four decimal places of a gigabyte before being compared, so an organization up to about 50 KB past its allowance rounded to equality and kept running. Reaching the allowance exactly now stops the traffic, one byte earlier than before, and the 100% alert and the stop land on the same byte instead of one apart. The advance notice this page promises is the 80% alert, which is unaffected.
• A mid-period plan change can no longer rewrite what you already used. The comparison is against what your organization was granted for the period, so moving between plans mid-month no longer re-judges traffic you moved under the other one.
• It trails a little further behind. The stop is applied on a sweep that reads settled measurements, so expect it within about ten minutes of passing the allowance rather than within two. It clears on the same cadence.

Your nodes stay online and your files stay where they are. Only transfers stop:

What you do	While the organization is over its allowance
Node-to-node sessions, published service traffic, new command sessions	stopped
Reading, writing, editing or copying files — on a node's disk or on a storage tree	stopped
Listing, stat, mkdir, deleting, renaming or moving, locking	works — you can still see, tidy and reorganize what you have
The node itself: online status, presence, the directory, net_* diagnostics, node_logs	unaffected
file op=fetch_url	works — the node fetches those bytes itself and they never cross noBGP's infrastructure

A command session that is already running keeps delivering its output; what is refused is starting a new one.

What a refusal looks like. Over a drive's HTTPS URL or a mounted drive, a GET, PUT or COPY is refused with 402 Payment Required — not 403, which would blame your permissions, and not the storage cap's 507, which would send you to delete files that are not the problem. From the file and command tools it is resource_exhausted with limit_type: "bandwidth", and the message names both ways out. An fs_copy is refused on either end, naming which one: the same bytes cross the router whichever direction they go.

Both ways out are real, and one of them is free. Wait for the billing period to roll over, or move the organization to a paid plan, where bandwidth above the allowance is drawn from a credit balance rather than stopped — and where a fleet with no credit to spend is slowed rather than cut off. Traffic resumes within a few minutes of either — enforcement is re-evaluated on a sweep and the stop lapses rather than being switched off by hand — so expect minutes, not an instant.

noBGP's support team can still reach your devices while an organization is stopped, so being over the allowance never means we cannot help you get back under it.

Plan limits

Bandwidth and compute are the two rows here that are meters; on every other axis, over the limit means creation is refused and there is no overage charge on any plan.

Resource	Free	Pro	Business	At the limit
Nodes	unlimited	unlimited	unlimited	— fair use on the paid plans, see below
Bandwidth	50 GB / period	100 GB / period included, then $0.12/GB	1 TB / period included, then $0.10/GB	Free: data traffic stops. Paid: drawn from your credit balance, then throttled to 1 Mbit/s per node when it is empty
Compute	$1 / period	$5 / period included, then from $0.02 / h	$50 / period included, then from $0.02 / h	Free: provisioning refused and running machines stopped. Paid: drawn from your credit balance — an empty balance refuses new provisions and stops the ones already up
Storage	10 GB	100 GB	1 TB	uploads are refused; reads and deletes keep working
Networks	unlimited	unlimited	unlimited	—
Services	unlimited	unlimited	unlimited	—
Members	unlimited	unlimited	unlimited	— members are free on every plan

The Free plan is genuinely free. Hard caps instead of overage, no card, no bill — beyond the bandwidth allowance the organization's data traffic stops until the period rolls over, with the nodes still online and never invoiced, and beyond the compute allowance provisioned machines are stopped rather than billed.

No plan caps devices any more, from router 0.4.106 — Free joined Pro, Business and Enterprise at unlimited, and the 25-node cap it used to carry is gone. A device that moves no data costs nothing to keep connected: an idle node's control traffic is about 1.5 MB a month and is not billed at all. What bounds an organization is the traffic its fleet moves, which is metered, alerted and — on Free — stopped.

Unlimited nodes carries a stated fair-use ceiling on the paid plans — about 1,000 live nodes per organization on Pro, 5,000 on Business — past that the right conversation is Enterprise, not an overage line. Free carries no fair-use number at all, for the same reason it no longer carries a cap. Nothing enforces the ceilings; they are policy, stated here so they are not a surprise.

How many free organizations one account may own

An account may own at most three organizations on the Free plan, from router 0.4.103 — the personal organization you get at signup counts as one of them. Creating a fourth is refused with a limit error naming the two ways forward: upgrade one of them to a paid plan, or have someone else own the next one.

Only ownership of free organizations is counted. You can be invited into any number of organizations you do not own, and paid and Enterprise organizations never count. Transferring ownership of a free organization moves it onto the recipient's budget, so a transfer that would take them past three is refused too.

Each free organization carries a full allowance of its own — 50 GB of bandwidth, $1 of compute, 10 GB of storage — which is why there is a ceiling on how many one person may hold.

Networks and services are unlimited on every plan (router 0.4.102). Free's plan row carried leftover caps of 1 network and 5 services from before the one-meter model — never enforced, because these gates were dark, but they were the numbers the system held. They are now zero, which is how "unlimited" is spelled everywhere else in the catalogue.

Free organizations get the same allowance alerts as paid ones from router 0.4.91, so the bandwidth allowance warns at 80% instead of arriving with no notice — which matters more since router 0.4.106, where what arrives is a stop rather than a slowdown.

Existing resources are never taken away: if you're over a limit when limits tighten, what you have keeps working — limits apply to creating more.

At the storage cap

The storage cap — 10 GB on Free, 100 GB on Pro, 1 TB on Business — is enforced from router 0.4.92 on Free and, from router 0.4.101, on paid plans too. It was a documented limit that nothing checked, on the one axis whose cost does not go away by itself; widening it to Pro is what keeps that true now that storage is a limit on every plan rather than a metered charge. It is pooled across everything the organization stores: every network's shared drive and every node's own storage area together.

What stops, and what does not. The test is does this add stored bytes, not is this a write:

Operation	At the cap
Uploading a file, copying one into the drive, creating a folder	refused — 507 Insufficient Storage over a drive's URL or a mounted drive, which most clients render as the disk is full rather than as a permission problem; resource_exhausted from the file tools
Reading, listing, downloading, copying out of the drive	works
Deleting	works — always, and deliberately
Renaming or moving within the drive	works, so you can reorganize your way to a delete

A cap that refused deletes would be a trap with no way out, so the way back under it is never blocked. The refusal names how much you are using against your allowance, and says that deleting still works.

This is not the bandwidth stop, and the two ask different questions. The storage cap asks does this add stored bytes — so reading is fine and creating a folder is not. The bandwidth stop asks does this move content — so reading is stopped and creating a folder is not. They answer with different codes for exactly that reason: 507 Insufficient Storage here, 402 Payment Required there.

Deleting is what clears it. The cap is measured against what you are storing right now, not against a period's peak — so uploads resume once the next storage measurement lands rather than at the end of the period. The measurement lags by at most one snapshot interval, a couple of minutes.

Emptying a node's storage area completely counts too, from router 0.4.94. The measurement is taken by listing what exists, and an area with nothing left in it is simply not listed — so through router 0.4.93 deleting some of a node's files released the cap while deleting all of them left that node's last measured level standing until it stored something again. A node the listing no longer sees is now recorded at zero. The only lag left is the measurement interval itself, a couple of minutes, which applies to every delete.

It applies to writes into noBGP's own storage, whichever way you reach it — over a drive's HTTPS URL, through a node's mounted drive, which is the same storage seen from the machine, and from router 0.4.93 through the file tools as well: fs_write, fs_mkdir and the destination end of an fs_copy addressed at a shared drive or a node's storage area. Those tools reach the same files without going through either of the HTTP doors the cap first shipped on, so on router 0.4.92 a write refused over the URL still succeeded through them. They answer resource_exhausted rather than 507 — the code every plan limit returns to a tool caller — and the message names fs_delete as the way back under the cap. Files on a node's own disk are the node's own and are not counted or capped at all.

If a payment fails

Grace first: a failed charge alerts you with no degradation while it's retried. Each failing invoice gets its own mail, from router 0.4.135 — retries of the same one do not repeat it, and a second invoice failing later in the same month is no longer swallowed as a duplicate. See the emails. If the subscription lapses:

• Existing nodes stay online, throttled to 1 Mbit/s each
• No new usage charges accrue while lapsed
• Creating new resources is blocked
• Running provisioned compute is stopped — the machine ends, with the node's identity and files kept

Everything restores automatically on payment — creation unblocks immediately, and the throttle lifts within a few minutes. No manual steps, no stuck states. A machine that was stopped comes back by provisioning its name again, which is the one step that is yours rather than automatic.