Seats, and how they are counted

A seat is the unit you are billed on, and the most common question about it is whether some particular thing counts. This article answers that, says exactly where the limit bites, and gives you the error text so that you recognise it the moment it appears rather than after twenty minutes of guessing.

What a seat is

A seat is one human being who is a member of your organisation. Concretely, it is one membership record: a person who has been invited and has a role in your organisation, whether that role is admin, member, viewer or something you created yourself.

Three consequences follow, and the third is the one people are usually asking about.

• A viewer costs the same as an administrator. The count is of memberships, not of privilege. An auditor with read-only access occupies a seat.
• A disabled account still occupies its seat until the membership is removed. Disabling stops somebody signing in; it does not free the seat. If you are near the ceiling, removing the membership of a leaver is the step that gives you room. There is a full leaver procedure in Who can see and do what.
• A person in two of your organisations occupies a seat in each. Membership is per organisation, and so is the count.

The membership list is the single source of the number. It is what the console's seat bar reads, and it is what blocks the next invitation, so the figure you are shown and the figure that stops you are the same figure. That sounds obvious and it was not always true: the seat usage field was once never assigned, so it serialised as zero and every tenant's usage bar read 0% regardless of how full they were. The bar is supposed to warn you before you hit the ceiling, and one that always reads empty warns nobody.

What is not a seat

A non-human identity is a service account, a CI runner, a scheduled job or an agent — something that authenticates but is not a person. These are not billed as seats. They sit in a separate allowance with its own numbers.

Above the pool on Core or Protect, nothing is auto-billed: it is a conversation after 60 days, the same fair-use approach as every other non-seat allowance, not a per-unit invoice line.

Endpoints are not seats either. The device allowance is 10, pooled, on Free, and 2 per person, pooled, on every paid plan — the figure to check if your firm is device-heavy: a laptop and a phone per person is 2.0, right at the line. Going over is billed automatically as an extra device in your next true-up rather than refused; protection never stops while you decide what to do about it. AI investigations are allowanced at 3 per person per month pooled (capped at 30) on Free and 20 per person per month pooled on every paid plan, and going over is explicitly not billable — if an investigation cost you money then our false positive would cost you money, which is the wrong way round. Beyond the pool the analysis degrades to an economy model and says so. Critical alerts are always investigated, on every plan including Free, and are never billed.

The identity limit, plan by plan

As of the 2026-09-27 pricing change, Free is the only plan with an actual membership ceiling. Every paid plan — Core, Protect and Complete alike — has none: you can invite as many people as you like at any of them, and the invitation that used to be refused on a smaller plan simply is not any more. Self-serve checkout does still enforce a minimum billable headcount per plan (10 people on Core, 5 on Protect, 5 on Complete) — that is a floor on what you are charged for, not a ceiling on how many people may join.

On Free, the comparison is greater-than-or-equal, so the limit is the number of memberships you may hold, and the invitation that would create the next one is the one refused. At 10 people you can have exactly ten; the eleventh invitation fails. That is the correct reading and it is worth being precise about, because 'we have 10 seats' and 'the 10th person failed' are the two readings people arrive with and only one of them is right.

An organisation with no licence record at all is treated as unlimited. That exists so that the very first administrator setting up a new organisation cannot lock themselves out before there is anything to license, and it is not a state a paying tenant is in.

What actually happens when you cross it

The check runs before the membership is created, on the add-member path. The invitation is refused; nothing is half-created; nobody who already had access loses it. Because only Free carries a ceiling at all now, this refusal is a Free-tenant experience in practice — a paid tenant on Core, Protect or Complete never sees it. The API answers 402 Payment Required with this body:

HTTP/1.1 402 Payment Required

{"error":"feature_not_available","feature":"max_users","required_tier":"professional"}

Internally the same condition is named user limit reached for current license, which is the phrase you may see quoted back in a support thread.

There is a second oddity in the same family. This 402 uses the key feature_not_available, while the entitlement gate that refuses a module you have not bought uses tier_upgrade_required. Two shapes of the same HTTP status exist in the product and they are not consistent with each other. If you are automating against the API, match on the feature field rather than on the error name.

Lowering a limit does not remove anybody

Nothing enforces the cap retroactively. If your licence is changed to a lower identity limit than the number of memberships you already hold, nobody is disabled, nobody is signed out, and no membership is deleted. The gate exists only on growth: you simply cannot add another person until you are back under the line.

That is a deliberate direction to fail in — the alternative is software that silently removes a colleague's access because of a billing change — but it means a downgrade can leave you sitting above your own ceiling for as long as you like, with the only symptom being that new invitations fail. If invitations start failing and you did not think you were near the limit, check whether the plan changed. Changing your plan covers the rest of what a downgrade does.

Changing your seat allocation yourself

You no longer have to ask anybody to move this number. Seat allocation can be edited directly from the Licensing screen at /licensing, where a Seats row shows your current allocation with an Edit button beside it. Pressing Edit turns the number into a field with Save and Cancel.

• You can lower it at any time, to any number you like.
• You can raise it as far as you like on any paid plan — Core, Protect and Complete carry no ceiling, so there is nothing here to hit. On Free, you can raise it up to 10 without contacting anyone.
• On Free, trying to go above 10 is refused, with a message naming the ceiling and that a paid plan removes it entirely. It is a clean refusal: nothing is half-applied.

Lowering the allocation does not affect anybody who already has an account. Nobody is disabled, removed or signed out. It only moves the point at which the next invitation is refused — the same behaviour described in the section above, applied to a number you chose rather than to one your plan chose.

Watching your seat usage

Your subscription summary reports seats used against seats available, alongside your tier, enabled modules, retention days and current period end. The usage bar turns red above 90%, which is the point at which you should be deciding rather than discovering.

One behaviour worth knowing: if the seat count cannot be read, the console returns an error rather than a zero. The message begins could not read seat usage: followed by the underlying reason. That is intentional. A seat count that cannot be read is not zero seats, and reporting zero would tell an administrator sitting at their ceiling that they had room — which is the single worst answer that surface could give.

1. 1

   Count the people who genuinely need an account

   Most staff do not. An account nobody uses is an account nobody notices being used, and it is also a seat. In a firm of forty, the honest number is often nearer fifteen.

2. 2

   Remove leavers' memberships, not just their access

   Disable the account first so their history stays attached to a real name, then remove the membership when you need the seat back. Check for API keys in their name at the same time.

3. 3

   Move service accounts out of the human count

   If a shared mailbox or a scanner has been given a membership, that is a seat being spent on something that is not a person. Non-human identities belong in the separate allowance.

4. 4

   Check the bar before you plan a hiring round

   On a paid plan there is no ceiling to run out of room under. On Free, room up to 10 you can give yourself on the Licensing screen in a few seconds; past 10 the answer is a paid plan, not a bigger Free allocation. Enterprise checkout involves a conversation rather than a self-serve one either way. Finding any of this out in the same week as three new starters is avoidable.

What to do next

1. Read The plans, and what each one includes for what each tier includes and its minimum monthly billable headcount — there is no annual floor on any self-serve plan any more.
2. If you are about to add people in bulk, Inviting your team is the procedure, and it will hit this limit before anything else does.
3. If an invitation failed and the error does not match the one above, send us the exact string and the timestamp. How to get help lists what makes that ticket answerable on the first reply.