Skip to content
Console

Known Limits

Use this page when an action is locked, unavailable, not showing, or behaving like a boundary rather than a setup failure. If the product says can’t add, start here before changing setup.

Billing is the source of truth for workspace limits. Service status is the source of truth for broad service incidents. This page helps you separate plan, usage, safety, service-status, and live-status boundaries from real setup problems.

  • a button is locked, disabled, or says upgrade required;
  • you cannot create another hub, connection, permission set, or private setup;
  • a skill update, runtime update, or hub update is unavailable;
  • a feature appears unavailable even though setup looks correct;
  • you need the current workspace limit;
  • a support request needs plan or usage context.
Limit areaWhere to confirm itWhat to capture
Current planBilling and PlansPlan name and the message beside the locked action.
Owned hubsBilling and PlansCurrent owned hub usage and limit.
ConnectionsBilling and Plans and Clients and ConnectionsCurrent usage, client state, and whether setup material exists.
Private skill setupsBilling and Plans and Skill SetsWhether the plan includes private skill setups.
Runtime configRuntimeSkill set assignment and runtime setting involved.
Skill, runtime, and hub updatesManage UpdatesUpdate owner, release target, and whether Billing allows the action.
AnalyticsBilling and Plans and AnalyticsWhether usage analytics need workspace hub capacity, plus selected range and filters.
Live statusLive MapConnected, stale, missing, warning, and filter state.
Service statusService statusCurrent incidents before reporting a broad outage.
Account securityProfile and SecurityTwo-step sign-in, recovery codes, and active browser status.

Owned hubs

If Billing shows the owned hub limit has been reached, reduce usage or change plan before creating another owned hub.

Connections

Connection creation, setup links, and connection file access can be limited by plan, usage, or account security checks.

Private skill setups

Private skill groups, shared runtime settings, and runtime updates depend on the workspace path shown in Billing.

Hub updates

Hub release operations depend on owned hub capacity. Check Billing before treating a locked update button as a product issue.

Hub addresses

Custom hub addresses are plan-controlled. Check Billing before treating an address message as a setup failure.

Runtime and Live Map issues can look like plan problems when the wrong hub, skill set, or client is being checked.

  1. Check Billing first when the product shows locked, disabled, unavailable, upgrade required, or limit reached.
  2. Check service status when several pages or teammates see the same broad problem.
  3. Check the owner page next when Billing says the plan allows the action and status is clear.
  4. Check Live Map last when Dashboard, Clients, and Permissions look correct but live state is missing or stale.

Some actions are intentionally blocked until account or data safety checks pass:

  • sensitive downloads can require account security checks;
  • setup links and connection files must stay private and should be rotated if exposed;
  • public support should not include tokens, passwords, API keys, client secrets, customer data, setup links, or connection files;
  • broad permissions should be split before adding more access.

If Billing or the owner page shows a limit that does not match what you expect, include this in your support request:

  • page or feature;
  • plan name;
  • current usage and limit;
  • visible status or message;
  • expected result;
  • actual result;
  • what changed recently.
Prepare a support request

You are done checking limits when:

  • Billing confirms whether the plan allows the action;
  • current usage is below or at the shown limit;
  • the owner page explains the next step;
  • any remaining issue has a support request with plan, usage, and visible status.