Organizations
How organizations work as shared workspaces — membership, roles, resource scoping, and the distinction between personal workspaces and team organizations.
Organizations
An organization is a shared workspace that groups monitoring resources — projects, services, integrations, alert rules, expectations, and incidents — under a common membership and role model.
Personal workspaces vs. team organizations
Every account automatically gets a personal workspace on sign-up. A personal workspace behaves like a single-user organization: you own all resources and there is no membership management, no SSO configuration, and no audit log.
A team organization is explicitly created (at sign-up or later) and supports:
- Multiple members with distinct roles (Owner, Admin, Member).
- SSO sign-in via OIDC, SAML 2.0, Google Workspace, or GitHub.
- Audit logging of organization-wide activity.
- Token oversight — Owners can see all API tokens issued to org members.
- Team and Enterprise plans with higher limits and shorter minimum check intervals.
You can belong to multiple organizations simultaneously and switch between them in the UI.
Resources and scoping
All monitoring resources belong to exactly one organization. When you are working in an organization context, you see only that organization's resources. The active organization is selected in the top navigation.
If you create a service or project while in your personal workspace, it belongs to your personal org. To move resources between organizations, you must recreate them (there is no bulk transfer).
Membership and roles
Each member holds exactly one role in an organization:
| Role | Description |
|---|---|
| Owner | Full control, including member management, SSO configuration, billing, and org deletion. |
| Admin | Can manage services, projects, integrations, and most settings. Cannot manage members or SSO. |
| Member | Can view and interact with monitoring resources based on fine-grained capability grants. |
Roles map to fine-grained capabilities (for example, service.edit or audit.view). The full capability matrix is in Roles & Permissions.
Inviting members
Owners and Admins can invite members by email from Settings → Members. Invitations can specify a role. An invited user who does not yet have an account creates one on accepting the invitation.
SSO and identity
Team organizations can configure single sign-on so members sign in through your organization's identity provider instead of (or in addition to) a password. See the SSO section for configuration guides for OIDC, SAML 2.0, Google Workspace, and GitHub.
Enforcing SSO requires all members to authenticate through the IdP. An Owner-level break-glass bypass can be granted per member for emergencies. See Per-Member SSO Password Bypass.
Audit log
The organization audit log records who did what and when, for compliance and security investigations. Owners and users with the audit.view capability can access it from Settings → Audit Log. See Audit Log.
API token oversight
Owners can view all API tokens issued to members of the organization from Settings → Token Oversight. Individual token values are never shown — only metadata (name, created date, last used). Owners can revoke any member token. See Token Oversight.
Service tokens
Organizations can issue service tokens — long-lived API tokens not tied to any individual member — for automation, CI/CD pipelines, and integrations like the Kubernetes autodiscovery operator. See Service Tokens.
Related
- Organizations: full docs — members, roles, SSO, audit log, email routing, token oversight
- Account — your personal account, login methods, and account merges
- API Reference — programmatic access to organization resources