Why limits exist

Every shared system has limits. They are not there to annoy you; they are there so one runaway script cannot take the service down for everyone.

Rate limits: how fast

A rate limit caps requests per window, for example 300 per minute. Go over and the server answers 429 Too Many Requests with a Retry-After header saying how long to wait. Well-behaved clients read the remaining budget from response headers and slow down before they hit zero.

Budgets are usually split by kind of work, so a chatty feature cannot starve an important one. Reads are cheap and safe to retry; writes are not, so they often get a separate, stricter budget.

Quotas: how much

A quota caps a total: storage used, users, emails per month, scheduled jobs. Quotas track a plan. Approach one and you get a warning; pass one and either the action is refused or overage is billed, depending on the resource.

What they protect

1. Availability: a burst from one tenant stays that tenant's problem.
2. Cost: storage and email have real per-unit prices.
3. Security: a login rate limit turns a million password guesses into a few hundred.

Reading a limit error

A 429 is not a bug in your app. Look at which budget ran out, wait the stated time, and if it keeps happening, reduce the request rate (batch, cache, poll less often) or move to a plan with a higher quota.

Where DontCode fits

The Usage page shows every plan-capped meter (app users, team seats, storage, emails, cron jobs and runs) against its cap, with warnings at 80% and 95%, plus a strip of the last seven days of throttled requests. The public API returns RateLimit headers on every response and a 429 with Retry-After when a per-minute budget is spent. Both kinds of limit are set per plan: quotas rise with the plan, and per-minute budgets can be tuned per plan as well. The RateLimit headers on each response, not the plan name, are the source of truth for how fast you may go.