Limits and Quotas
Who this is for
Admins and developers planning scale or automation.
Goal
Understand tenant object limits and how a plan or temporary override changes them.
Prereqs
- Tenant administrator access to Plan & Usage to see your tenant's effective limits.
Success criteria
You can check available capacity and know what to do when an operation reaches a limit.
Default object limits
These operational defaults apply per tenant unless your plan or a tenant-specific override sets a different value. They are not fixed maximum plan sizes.
| Item | Default | What counts |
|---|---|---|
| Active identities | 10,000 | Non-deleted human identities that are not terminated; suspended identities still count |
| Total identities | 50,000 | All non-deleted identities, including service accounts and terminated identities |
| Installed integrations | 250 | Integrations not deleted or being deleted, including disabled and unconfigured integrations |
| Custom connectors | 100 | Non-deleted custom connectors |
| Gateways | 50 | Gateways that have not been revoked, including pending enrollment |
| Resources | 10,000 | Non-deleted resources |
| Reactions | 500 | Reaction definitions |
| Access review definitions | 500 | Review definitions, not individual review runs or review items |
| Functions | 250 | Non-deleted functions |
| Custom attributes | 250 | Tenant-defined custom attributes |
| Policies | 2,000 | Policies that are not disabled, including drafts |
| API keys | 100 | Active API keys |
Plans and overrides
The effective limit uses the first applicable value:
- An unexpired tenant-specific override.
- An explicit value in your assigned plan.
- The operational default above.
A plan or override can raise or lower an object limit. An explicit unlimited value removes that count limit; an omitted value inherits the default. Contact Owlie to arrange plan changes or tenant-specific overrides. Overrides may expire, at which point the plan value or default applies again. Changes normally propagate within about a minute.
Operational object limits apply to both administrator actions and automation. Commercial observation or grace settings do not suspend them. Lowering a limit does not delete existing objects: if usage is above the new limit, reduce usage or arrange a higher limit before adding more counted objects. Removing objects and revoking access remain available.
Sync and concurrency
When an identity limit is reached, synchronization skips new identities that would exceed it and reports them as skipped over limit. Existing-identity updates and terminations continue; transitions that increase the active-identity count still require capacity. Sync uses a usage snapshot for each run, so concurrent writers can exceed the count limit. Existing objects are still retained when this happens.
Provisioning normally runs up to 4 concurrent jobs per tenant, with 1 additional slot reserved for revocation work. Sync normally runs up to 3 concurrent jobs per tenant. Plan values or overrides can adjust provisioning concurrency within 1–4 and sync concurrency within 1–6. These concurrency ceilings are runtime safeguards, unlike the overridable object defaults above. Extra jobs wait in their queues; they are not discarded.
These are object and job-concurrency limits, not a complete list of API request-rate, payload-size, or custom-code execution limits.
Example
A tenant with no explicit resource limit can have 10,000 resources. A plan setting the limit to 25,000 replaces that default. A temporary tenant override of 30,000 takes precedence until it expires, after which 25,000 applies again. Resources already created are not removed.
Troubleshooting
- Check Plan & Usage (
/admin/usage) for current usage and effective limits. Displayed counts may lag writes briefly; admission checks use current counts. - A limit error identifies the affected limit, current usage, and allowed count. Remove unused objects or request a higher limit before retrying. Smaller batches only help when some capacity remains.
- If sync reports skipped-over-limit identities, free capacity or increase the limit, then run sync again.
- If a limit cannot be checked, the write can fail temporarily. Retry after the service recovers; an unavailable check does not grant extra capacity.