Billing and Limits
Watasu billing is prepaid: you top up a balance, and usage draws it down as it happens. There’s no end-of-month invoice surprise — what you can spend is bounded by what you’ve loaded.
How the balance works
Section titled “How the balance works”- Top up from the dashboard with a payment card. The amount lands on your team’s balance immediately.
- Usage is metered continuously — app compute and add-ons are metered minute by minute, sandboxes second by second — and charged against the balance.
- Auto top-up is optional. Enable it if you’d rather never think about the balance; leave it off if you want a hard ceiling on spend.
- Low-balance warnings arrive before anything is affected, so you have time to top up.
If the balance runs out, the team is suspended: deploys are blocked, running workloads are paused, and sandbox creation and commands are refused (stopping and destroying sandboxes still works, so you can always clean up). Topping up lifts the suspension.
Every charge is visible in the dashboard’s billing view, itemized per app, add-on, and sandbox, with a current-month running total.
What you pay for
Section titled “What you pay for”| What it is | |
|---|---|
| App compute | Pod count × pod size × time, metered per minute. Bigger pods and more replicas cost more. |
| Add-ons | Each add-on plan has its own monthly price, metered per minute while provisioned. Higher tiers add capacity, durability, replication, and scheduled backups. |
| Sandboxes | vCPU-seconds and GiB RAM-seconds while running, plus retained disks, checkpoints, and template storage. |
| Observability | Logs, metrics, and traces have plan-tiered ingest, retention, and active series limits. |
Prices are listed per month for readability, but nothing bills in monthly blocks — destroy an add-on after a day and you’ve paid for a day.
Limits that shape usage
Section titled “Limits that shape usage”Depending on the area:
- runtime — max replicas per process, max pod size;
hobbypods cap at one replica - storage — database storage size, object storage size and egress allowance
- sandboxes — maximum sandbox TTL, CPU/memory/disk runtime limits, retained disk, checkpoint, and template storage
- monitoring — active metric series, log ingest rate, log retention window
- add-on connections — each database plan has a connection ceiling; size your pools to fit
When you hit a plan limit, the fix is almost always a plan upgrade, not a workaround. The plan catalog in Add-on Plans lists the ceilings per tier.
Plan choice is a workload decision
Section titled “Plan choice is a workload decision”Plans aren’t just a price tier. They shape:
- durability and replication
- scheduled backups vs. manual-only
- query and ingest performance
- retention windows
Pick based on what your workload actually needs. The cheapest plan that fits is the right one — but if you guess wrong upward (over-provisioned) you waste money, and if you guess wrong downward (under-provisioned) you wake up at 3am.
See Add-on Plans for the full plan catalog and Sandbox Billing for sandbox runtime and storage billing.
- match plans to workload, not to the price ladder
- keep staging on smaller plans than production
- review observability plans before a traffic surge — log ingest is a common surprise
- if you run automation that creates sandboxes, set timeouts and destroy on completion
- enable auto top-up for production teams; a paused app costs more than a top-up