Summary and recommendation
Atlassian Statuspage user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Atlassian Statuspage uses a two-layer permission model: product-level roles (Site Admin, Product Admin, Product User, Billing Admin) managed in admin.atlassian.com, and page-level permissions managed in manage.statuspage.io. On Business plans and above, per-page RBAC sub-roles (Incident Manager, Maintenance Manager, Viewer) add a third layer of granularity. No custom roles are supported at any tier.
Team member seats are plan-level allocations, not per-seat charges - the plan price is fixed per subscriber tier. Seat caps range from 2 (Free) to 50 (Enterprise), with additional slots available as add-ons via Atlassian support.
SCIM provisioning requires an Atlassian Guard subscription. SSO must be configured before SCIM can be enabled, and SCIM API keys expire after one year with no automated renewal.
Quick facts
| Admin console path | Avatar (top-right) → Users (within manage.statuspage.io); broader org-level user management at admin.atlassian.com → Products → Statuspage → Manage access |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Atlassian Guard subscription |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Site Admin (Organization Admin) | Full control over all Statuspage settings, pages, and users. Can invite new team members, change user access levels, remove or suspend users, and manage product access groups in admin.atlassian.com. Has access to all pages by default. | Cannot revoke access from 'Trusted Users' directly; must downgrade them to basic user role or elevate to site admin first. | All plans | Counts toward team member seat allocation | Site admins are included in the Statuspage product access group by default. If this is not intentional, the site-admins group must be manually removed from Statuspage product access in admin.atlassian.com. |
| Product Admin | Can grant and manage role permissions for other users. Has access to all pages by default. Can create incidents, update component statuses, configure pages, and manage team member page permissions. | Cannot change a user's product role level (that requires a site admin acting through admin.atlassian.com). Cannot remove team members from the organization. | All plans | Counts toward team member seat allocation | Users invited via admin.atlassian.com are granted all page and role permissions by default, bypassing any page-level restrictions set in manage.statuspage.io. |
| Product User (Team Member) | Default role for users invited through manage.statuspage.io. Can create incidents, update component statuses, and manage pages they have been granted access to. Access can be scoped to specific pages via page permissions. | Cannot remove other team members. Cannot change user access levels. Cannot access pages they have not been explicitly granted access to (when page permissions are configured). | All plans | Counts toward team member seat allocation | When invited through Statuspage directly, users receive the Product user role by default. When invited through admin.atlassian.com, the inviter can optionally assign Product admin access. |
| Billing Admin | Receives all Statuspage invoices and manages billing. Not strictly linked to product roles; any user can be granted billing admin permissions through the billing console. | Billing admin role alone does not grant access to manage incidents or page content. | All plans | Does not independently consume a seat unless the user also holds a product role | Added as a distinct role in June 2024. The person who signs up for a new Statuspage automatically receives the Billing admin role for all Statuspage entitlements. |
| RBAC Sub-roles (per page): Incident Manager, Maintenance Manager, Viewer | Three additional per-page roles assignable within RBAC. Incident Manager can create/manage incidents. Maintenance Manager can create/manage scheduled maintenance. Viewer has read-only access to the management interface for assigned pages. | Sub-roles are scoped per page; a user with only a Viewer sub-role cannot create incidents or modify components on that page. | Business, Corporate, Enterprise, or Audience Specific plans only | Counts toward team member seat allocation | Only Statuspage product admins can grant and manage RBAC role permissions. Users invited via admin.atlassian.com receive all page and role permissions by default, bypassing RBAC scoping. |
| Trusted User | Atlassian-level designation that automatically grants access to all products in the organization, including Statuspage. | Trusted user product access cannot be revoked directly. | All plans | Counts toward Statuspage user/seat allocation | To remove a Trusted User from the Statuspage license count, they must be downgraded to a basic user role, or elevated to site admin so their access can then be revoked. |
Permission model
- Model type: role-based
- Description: Statuspage uses a two-layer permission model. The first layer is product-level roles (Site Admin, Product Admin, Product User, Billing Admin) managed in admin.atlassian.com. The second layer is page-level permissions (which pages a user can access) and, on Business/Corporate/Enterprise/Audience Specific plans, RBAC sub-roles (Incident Manager, Maintenance Manager, Viewer) scoped per page. Page permissions are managed within manage.statuspage.io by product admins. Only site admins can change product-level roles.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Page-level scoping available on all plans with 2+ pages. Per-page RBAC sub-roles (3 roles) available on Business, Corporate, Enterprise, and Audience Specific plans only. No custom role creation is supported.
How to add users
- Log in to manage.statuspage.io.
- Click your avatar in the top-right corner.
- Select 'Users' from the menu.
- Click 'Add user'.
- Enter the new team member's email address.
- Click 'Create'.
- The new team member receives an email invitation.
- Alternatively, site admins can add users via admin.atlassian.com → Products → Statuspage → Manage access → Add groups or users directly.
Required fields: Email address
Watch out for:
- Only site admins can directly invite new team members. Non-site-admin team members can submit an invite request, but a site admin must approve it in Atlassian admin > Access requests under User management.
- Users invited through manage.statuspage.io receive the 'Product user' role by default.
- Users invited through admin.atlassian.com receive all page and role permissions by default, bypassing any page-level restrictions.
- The number of team members that can be added is capped by the plan's team member allocation. Free: 2, Hobby: 5, Startup: 10, Business: 25, Enterprise: 50.
- Current team member usage is visible under 'User management' in the profile menu at manage.statuspage.io.
- Additional team member slots can be purchased as add-ons by contacting Atlassian support.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Atlassian Guard subscription (SCIM 2.0). SSO via Guard Standard is included at no extra charge for Statuspage users on Startup, Business, and Enterprise plans. Guard Standard is required for SAML SSO. Group sync is not available for Statuspage via SCIM. |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Two options exist, both managed via admin.atlassian.com (not manage.statuspage.io directly). 'Remove' revokes the user's access to the Statuspage site immediately; they are not billed for that site after removal, but their Atlassian account is not permanently deleted and they retain access to other sites/organizations. 'Suspend' temporarily removes access and stops billing for that user on the site; roles and group memberships are restored when access is reinstated. Permanent account deletion is only possible for managed accounts and must be done separately via admin.atlassian.com.
- Go to admin.atlassian.com.
- Select your organization (if more than one).
- Navigate to User management.
- Find the user to remove or suspend.
- To remove: select 'Remove user' - this revokes site access immediately and stops billing for that user on that site.
- To suspend: select 'Suspend access' - this temporarily removes access and stops billing; roles and group memberships are restored on reinstatement.
- Alternatively, to remove a user's Statuspage product access specifically: go to admin.atlassian.com → Products → Statuspage → Manage access, then remove the user or their group from Product access.
| Data impact | Behavior |
|---|---|
| Owned records | Incidents, components, and maintenance records created by the removed user remain on the Statuspage; they are not deleted when the user is removed. |
| Shared content | Page content, subscriber lists, and integrations are unaffected by team member removal. |
| Integrations | API keys and integrations configured by the removed user remain active; they must be manually reviewed and rotated if the user had access to API credentials. |
| License freed | Billing stops for the removed or suspended user on that site immediately upon removal or suspension. |
Watch out for:
- There is no option to remove users directly from manage.statuspage.io; removal must be performed in admin.atlassian.com.
- Removing a user from a Statuspage site does not remove them from other sites in the organization or permanently delete their Atlassian account.
- Trusted User product access cannot be revoked directly; the user must be downgraded to a basic user role or elevated to site admin before access can be removed.
- Only organization admins can deactivate or delete a user across the organization; site admins can remove users from their specific site.
- If the original account owner/site admin has left the company, Atlassian support must be contacted to reassign ownership.
- Removing a user and re-inviting them requires reassigning all roles and group memberships from scratch.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Team Member (Public Page - Free) | 2 team members, 100 subscribers, 25 components, 2 metrics | Free |
| Team Member (Public Page - Hobby) | 5 team members, 250 subscribers, 5 metrics | $29/month |
| Team Member (Public Page - Startup) | 10 team members, 1,000 subscribers, 10 metrics; SSO via Atlassian Guard Standard included for Statuspage users | $99/month |
| Team Member (Public Page - Business) | 25 team members, 5,000 subscribers, 25 metrics; RBAC; SSO via Guard Standard included for Statuspage users | $399/month |
| Team Member (Public Page - Enterprise) | 50 team members, 25,000 subscribers, 50 metrics; RBAC; SSO via Guard Standard included for Statuspage users | $1,499+/month |
| Team Member (Private Page - Starter) | 5 team members, 50 authenticated page users | $79/month |
| Team Member (Audience Specific Page) | Team member allocation varies; audience-specific user groups and components | From $300/month (10 groups, 500 users) |
- Where to check usage: manage.statuspage.io → Avatar (top-right) → User management (shows current team member count vs. plan allocation). Billing details at admin.atlassian.com → Billing → Manage subscriptions.
- How to identify unused seats: No built-in last-login or activity report is available in Statuspage. The activity log (manage.statuspage.io → Activity log) shows recent actions but does not provide a per-user inactivity report. Admins must manually cross-reference the Users list against the activity log to identify inactive team members.
- Billing notes: Team member seats are plan-level allocations, not per-seat charges; the plan price is fixed per subscriber tier. Additional team member slots can be purchased as add-ons by contacting Atlassian support. Statuspage users on Startup, Business, and Enterprise plans receive Atlassian Guard Standard (SSO) at no extra charge for Statuspage-only users; users who also access other Atlassian products (e.g., Jira) will incur a separate Guard Standard charge for those products. SCIM provisioning requires an Atlassian Guard subscription. SCIM API keys expire after 1 year and must be rotated. Group sync is not supported for Statuspage via SCIM.
The cost of manual management
Every app has an offboarding edge case, and Statuspage's is the Trusted User designation: access cannot be revoked directly. Admins must first downgrade the user to a basic role or elevate them to site admin before removal is possible - a non-obvious workaround that is easy to miss under time pressure.
User removal itself cannot be performed from manage.statuspage.io. Admins must navigate to admin.atlassian.com, creating a split-console workflow that adds friction to every offboarding action.
Identifying inactive seats compounds the problem. Statuspage has no built-in last-login report or per-user inactivity view. Admins must manually cross-reference the Users list against the activity log - a process that does not scale as team size grows.
What IT admins are saying
The most consistent friction point reported by admins is the split between manage.statuspage.io and admin.atlassian.com. User removal, role changes, and suspension all require leaving the Statuspage console entirely, which creates confusion and increases the chance of incomplete offboarding.
A second recurring issue is the invitation path side effect: users added via admin.atlassian.com receive all page and RBAC permissions by default, bypassing any page-level restrictions already configured in manage.statuspage.io.
Teams that rely on page scoping for least-privilege access must audit every invite made through the Atlassian admin path.
The SCIM API key expiry (one year, mandatory rotation as of January 2025) is flagged as an operational risk. There is no automated warning, and a lapsed key silently breaks provisioning until manually rotated.
Common complaints:
- No option to remove users directly from manage.statuspage.io; admins must navigate to admin.atlassian.com, creating a confusing split UX between the two consoles.
- Trusted User access cannot be revoked without a workaround (downgrade to basic role or elevate to site admin first), which is non-obvious and underdocumented.
- Users invited via admin.atlassian.com receive all page and RBAC permissions by default, bypassing any page-level restrictions configured in manage.statuspage.io.
- RBAC sub-roles (Incident Manager, Maintenance Manager, Viewer) are only available on Business, Corporate, Enterprise, and Audience Specific plans, locking granular access control behind higher-cost tiers.
- No built-in inactive user report or last-login visibility; identifying unused seats requires manual cross-referencing of the Users list and activity log.
- SCIM API key expires after 1 year and must be manually rotated; no automated renewal or warning system is prominently documented.
- Group sync is not available for Statuspage via SCIM/Atlassian Guard, requiring manual group and role assignment after provisioning.
- Additional Guard Standard cost applies if Statuspage team members also use other Atlassian products (e.g., Jira), making cost estimation complex for mixed-product organizations.
- If the original account owner leaves the company, ownership transfer requires contacting Atlassian support; there is no self-service ownership transfer.
- Community reports of confusion between 'site admin' and 'account owner' roles, with site admins unable to see the delete-user option that the documentation describes as available to owners.
The decision
Manual management is viable for small teams on Hobby or Startup plans where seat counts are low and turnover is infrequent. The two-console workflow is manageable at that scale, and the lack of an inactive-user report is a minor inconvenience rather than a real risk.
At Business plan and above - where RBAC sub-roles, larger seat allocations, and stricter compliance requirements apply - the absence of automated provisioning and activity reporting becomes a meaningful gap. Every app in a mid-size or enterprise stack that lacks automated deprovisioning is a potential audit finding.
Teams already running an IdP (Okta, Entra ID, Google Workspace) should evaluate the Guard SCIM path. The key constraints to weigh: group sync is not available for Statuspage, page permissions still require manual configuration, and Guard adds a per-user cost across the entire Atlassian organization.
Bottom line
Atlassian Statuspage's manual user management is functional but split across two consoles, with no inactive-user reporting and a non-obvious Trusted User offboarding workaround. For small teams with low churn, the overhead is manageable.
For teams on Business plans or above - where RBAC, larger seat caps, and compliance expectations apply - the manual process introduces real operational risk: every app without automated deprovisioning is a liability when auditors ask for access evidence.
The Guard SCIM path closes the provisioning gap but does not eliminate the need for manual page-permission management, and the one-year API key expiry requires a standing operational reminder to avoid silent provisioning failures.
Automate Atlassian Statuspage workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
