Reference
Limits and quotas
Per-plan limits, export caps, and product-level caps you'll hit when scaling clusters and members.
You're trying to invite a thirteenth teammate, or you just exported a CSV and it stopped at 10,000 rows, or your finance lead wants to know how many clusters fit on the current plan. This page lists every limit Kubeadapt enforces today and where to see your current usage.
Two kinds of limits live in the product: per-plan limits that show up under Settings → Billing with a usage meter, and per-feature caps that apply to every plan (export row counts, attribution team splits, and so on).
Per-plan limits
The Billing tab (Settings → Billing) shows four usage meters for the current 30-day window. The same four meters cover everything the plan tracks today — there is no namespace limit and no API rate-limit meter on this page.
| Meter | What it counts | Display unit |
|---|---|---|
| Clusters | Connected clusters in the organization | count |
| vCPU avg (30d) | Mean vCPU averaged over the trailing 30 days | vCPU |
| Members | Organization members with any role | count |
| Data retention | Days of cost data retained for queries | days |
Each meter shows used over max. Unlimited values render as the infinity glyph and the meter labels itself "Unlimited".
When the used value reaches the max, the meter fills green ("Full"); above 80%, it shifts to amber. Members and clusters block at the max; vCPU and data retention show the cap visually but don't block data collection — they're billing signals, not enforcement gates.
Where the values come from
The current-plan max values come from your billing configuration and render straight onto the meters. Trial plans typically expose smaller maxes than the Enterprise contract; the trial-end date is also shown in the hero card.
Retention specifics
The data-retention meter shows current retention in days against your plan's maximum. When the retention max is 365 or more, the label switches to year-rounded form: "Full — 1-year retention" instead of "Full — 365-day retention".
Cost Explorer export caps
Both the CSV and PDF exports cap their output. Bigger queries don't fail — they return the first N rows with a toast asking you to narrow filters.
| Export | Cap |
|---|---|
| CSV | 10,000 rows |
| 500 rows |
The cap applies after the current group-by, filters, cost mode, and time window are applied. If you need a larger CSV, group at a coarser level (namespace instead of pod, controller instead of container) or narrow the date range.
PDF exports are designed to be shareable artifacts — 500 rows fit cleanly into the report layout. CSV is the path when you need the full dataset; for queries that would exceed 10,000 rows, run multiple exports broken up by namespace, cluster, or time slice and concatenate.
Attribution caps
Maximum teams per workload (10)
Every namespace, workload, or PV can be cost-split across up to 10 teams, with percentage weights that must sum to 100. The limit applies to all three entity kinds.
- Where it bites: the "Split cost" dialog in the Assignment Workbench refuses to add an 11th team; submitting via API with more than 10 weighted-team entries returns a validation error.
- Why: 10 teams covers virtually every real chargeback scenario.
If you need to attribute cost across more than 10 teams, build the split at the namespace level instead of the workload level (so the same 10-team split applies to every workload in the namespace), or use Departments — a Department can hold any number of Teams.
Label-based attribution
Label-based attribution has no cap on the number of distinct label values. The 10-team cap only applies when you're manually splitting cost in the Workbench.
Recommendation caps
POC monthly savings threshold ($300)
Proof-of-concept (POC) organizations can only realize savings from workloads whose monthly savings fall under $300. Above the cap, recommendations surface with a locked-card overlay until you convert to a paid plan.
This cap is not enforced on paid plans — Enterprise and other paid tiers see every recommendation regardless of savings size.
Channel and rule caps
Smart Alerting doesn't enforce hard caps on the number of rules or channels per organization — they're soft-limited by plan tier and part of contract negotiation, not a frontend block. The four supported channel kinds are:
- Slack — incoming webhook URL.
- Email — distribution list.
- Webhook — POST to a configured URL with the incident payload.
- In-app — bell icon in the Kubeadapt UI.
The four configurable alert types are documented in Smart Alerting → Rules.
What's not capped
A short list of things readers sometimes assume are capped but aren't:
- Namespaces per cluster — no limit. Every namespace the agent observes is captured.
- API rate limits — not surfaced on the Billing tab. Rate limits exist at the API gateway; if you're hitting them on programmatic access, contact support.
- Dashboards saved per user — no hard cap.
- Reports archived — no hard cap.
- Snapshot frequency — set on the agent via
KUBEADAPT_SNAPSHOT_INTERVAL(default 60s). Lower intervals are allowed but raise the data-collection load on your cluster and on Kubeadapt.
See also
- Cost modes — the Fully Loaded vs Workload Only model behind the cost-mode toggle on every export.
- Cost Explorer — where the CSV and PDF exports originate.
- Assignment Workbench — where the 10-teams-per-entity split is enforced in the UI.