# Billing and Limits

> Prepaid balance billing, what you pay for, and the limits that shape app and add-on usage.

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

* **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

|               | What it is                                                                                                                                                                                                                                     |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| App compute   | Fixed plans charge per replica and provisioned time. Dynamic plans charge measured CPU and memory, with a €0.30 minimum per running replica-month and a size-specific ceiling. See [Pod Sizes](https://docs.watasu.io/reference/pod-sizes.md). |
| 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     | The team's Basic, Pro, or Enterprise plan, plus vCPU-seconds and GiB RAM-seconds while running and retained disks, checkpoints, and template storage. Pro is €150/month; usage is separate.                                                    |
| Observability | Logs, metrics, and traces have plan-tiered ingest, retention, and active series limits.                                                                                                                                                        |

App compute and add-on prices are listed per month for readability and prorated by usage time — destroy an add-on after a day and you've paid for a day. Sandbox Pro is a separate monthly team subscription; its cancellation and refund terms are described in [Sandbox Billing](https://docs.watasu.io/sandboxes/billing.md).

## Limits that shape usage

Depending on the area:

* **runtime** — max replicas per process, max pod size; `hobby` pods 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](https://docs.watasu.io/reference/addon-plans.md) lists the ceilings per tier.

## 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](https://docs.watasu.io/reference/addon-plans.md) for the full plan catalog and [Sandbox Billing](https://docs.watasu.io/sandboxes/billing.md) for sandbox runtime and storage billing.

## Tips

* 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

[View this page on the web](https://docs.watasu.io/admin/billing-and-limits/)