Running core limits
A concurrent running core limit caps how many cores your workspace can have running at the same time, across every member. It is a ceiling on simultaneous consumption, not a budget: it says nothing about total spend, and it does not reset monthly.
Find it at Workspace Admin > Policies > Running Core Limits. The page itself is titled Concurrent Core Limits.
This page is read-only
Limits are set by Rescale, not by you. A workspace administrator can see which limits apply but cannot change them, and there is no Save button on the page.
To raise a limit, contact your Account Executive or email support@rescale.com.
What a row means
Each row is one limit, and a limit is a combination of four things rather than a single number. It names a coretype, the workload types it counts, the region it applies in, and only then the ceiling itself. So a row reads as "at most N cores of this coretype, for these workload types, in this region", and changing any one of those three qualifiers describes a different limit.
That structure is why the page usually has several rows and why a member can be blocked on one coretype while another is wide open.
What happens when you hit a limit
Work is not rejected. A job that would exceed the limit waits until enough cores free up, in the same way it waits for capacity, and then starts. If members report jobs sitting in a pending state while the platform reports capacity as available, an exhausted core limit is worth checking before you look at anything else.
Because the cap is workspace-wide, one member running a very large job can hold up everyone else's work. Where that matters, pair the limit with budgets or a per-project cap so no single team can consume the whole allowance.
Rescale has several limits that all read as "you can only use so much", and they are set in different places by different people, so it is worth knowing which one you are looking at.
Running core limits, this page, cap concurrent cores across the whole workspace and are set by Rescale. Max Concurrent Active Cores is the same idea narrowed to a single project, and it sits on the project itself under Teams > Projects, where you can change it yourself. Budgets cap total spend over a period rather than how much runs at once, which means a workspace can be inside its budget and still blocked by a core limit. Storage and transfer limits cap data volume and have nothing to do with compute at all.
Related
- Job priority — what a job waits for, and the priority models
- Budgets & Deposits — capping spend rather than concurrency
- Cluster health — diagnosing a job that is not starting
- Workspace Policies — the rest of the Policies menu, and which parts of it are documented elsewhere