Teams, organizations and roles

Everything in CompleteStatus belongs to an organization — your billing and team boundary. Inside it, projects group related monitors, alert channels and status pages (one project per site, or per client, works well).

Organizations and projects

An organization is created automatically with your account; you name it in the first step of the onboarding wizard at /onboarding. Your plan, its limits (monitor count, check interval, retention) and its feature flags all live at the organization level — see Getting started for the plan table.

Projects are the unit of day-to-day grouping:

• Monitors, alert channels and maintenance windows belong to a project.
• Status pages publish a project's monitors.
• Client-role members (below) are granted access per project.

Roles and what they can do

Each member of an organization has exactly one role:

In practice:

• Owner / Admin are the management roles: only they can open /settings/api-keys and /settings/audit-log, delete projects, and administer the organization.
• Member is the working role: create and edit monitors, alert rules and channels, but no organization administration.
• Viewer sees everything in the organization, read-only.
• Client is view-only and restricted: a client membership carries a list of allowed projects, and the client can only see those.

Note: There is currently no self-serve invitation screen in the app — organization membership and roles are managed at the account level rather than from a settings page. The permissions above are enforced everywhere regardless of how a membership was created.

The client role for agencies

The client role exists so an agency or MSP can give each customer a login that sees only their own project — their monitors, uptime and incidents — and nothing about the agency's other customers.

The pattern:

1. Create one project per customer ("Acme Corp", "Beta Ltd", …).
2. Give each customer's user the client role, scoped to their project.
3. Optionally publish a status page per project for a fully public view — Agency plans support up to 100 status pages and white-label branding.

A client user cannot create or edit anything, cannot see other projects, and cannot reach organization settings, API keys or the audit log.

Note: The client role is a plan feature: it's included on the Business and Agency plans. Agency additionally includes the reseller/white-label package (white-label PDFs and reports, bulk audits up to 500 domains) — see Security-posture scans for the audit tooling.

Two-factor authentication

CompleteStatus supports TOTP two-factor authentication (standard authenticator apps such as Google Authenticator, 1Password or Authy).

When an account has 2FA enabled, signing in adds a second step:

1. Enter your email and password as usual.
2. On the two-factor screen, type the 6-digit code from your authenticator app.
3. Lost the device? Click through to the recovery option and enter one of your emergency recovery codes instead.

Two-factor codes are rate-limited (5 attempts per minute) to blunt brute-forcing, and enabling 2FA requires confirming a code from the app, so you can't lock yourself out with a mistyped secret.

Warning: Store your recovery codes somewhere safe when you enable 2FA. Each is single-use, and they are the only way in if your authenticator device is lost.

The organization audit log

Owners and admins can review everything that changed in the organization at /settings/audit-log:

• Who — the acting user (or system) on every entry.
• What — the action performed; the action dropdown lists every action type recorded in your organization.
• When — filter by date range (from / to).

Filter by action, actor and date; results are paginated 25 per page. Each row can be expanded to reveal the entry's recorded properties — sensitive values are redacted before they're stored, so secrets never appear in the log.

Use it to answer questions like "who deleted that monitor?", "when was this alert channel changed?", or "which API key was created last week and by whom?".

Security housekeeping for admins

1. Keep the Owner/Admin set small — those roles control API keys and billing.
2. Give day-to-day users Member; give stakeholders Viewer; give customers Client.
3. Review /settings/api-keys periodically: check each key's last-used time and revoke anything stale. Prefer keys with an expiry (set in days at creation).
4. Skim the audit log after incidents or personnel changes.

Related guides

• The REST API — API keys are managed by owners and admins.
• Getting started — plans, limits and onboarding.
• Security-posture scans — the security features every role can view.
• White-label monitoring for agencies — the client-role and reseller workflow in practice, on the blog.