Team
A workspace belongs to your organisation, not to one person. Whoever reports an incident at three in the morning is rarely the person who set the status page up — so it is worth adding your team early rather than during the first real outage.
Inviting someone
Under Invitations in the dashboard you enter one or more email addresses and pick a role. The people you invite receive an email with a link; they accept it under My invitations in their own account.
Someone without an account signs up through the link with exactly the invited address — this works even while sign-up otherwise needs a beta invite. Invited people get no workspace of their own; they land straight in yours: one company, one workspace.
An address that is already on the team, or already has an open invitation, is rejected — so nobody can be invited twice by accident.
Through the API you list members (if you may manage the team) and open invitations (if you may invite), invite and withdraw invitations (/api/v1/team/…). People invited through the API always get the member role; removing members and giving or changing roles is dashboard-only.
Roles
There are two:
| Role | Can |
|---|---|
| Admin | Everything, including workspace settings, the mail server, billing and managing the team |
| User | Work with the status pages: create and maintain incidents and maintenance windows, manage components and subscribers |
A role can be changed later at any time under Users.
Access per status page
A member starts with every status page. Under Team → Status page access you, as an admin, decide for single members what they may do on each page:
| Access | Means |
|---|---|
| Edit | Everything on that page: incidents, maintenance, components, subscribers, settings |
| Read only | See the page's entries, change nothing |
| No access | The page does not exist for that member |
Once you restrict a member, only what you set counts. Pages added later stay hidden until you grant them. A restricted member adds no new status pages and does not see the audit log. Admins always reach every page.
It applies everywhere: in the dashboard, through the API and the MCP server. A member's API tokens have the same limits as the member. With four-eyes approval, only someone who may edit the page approves. Every change to access is in the audit log.
How many seats you have
The number of team members depends on your plan — Starter is limited to a few seats, Business has no ceiling. The exact figures are in the plan comparison.
Open invitations already take a seat. Once the plan is full you cannot invite anyone until you withdraw an invitation, remove someone or change plans. An invitation accepted after the plan filled up (after moving to a smaller plan, say) is turned down.
Once the allowance is used up you cannot invite anyone else until you either remove somebody or change plan.
Why this matters for four-eyes approval
Four-eyes approval requires that somebody other than the author releases an entry. In a workspace of one that would leave every incident waiting forever — which is why the setting has no effect there, even when it is switched on.
Put simply: a second team member is what makes approval do anything at all.