Visibility Modes
Every status page has a visibility setting that controls who can view it:
| Mode | Access | Auth Method | Plan |
|---|
| Public | Anyone on the internet | None | All plans |
| Private | Users with the password | Password | Pro+ |
| Internal | Users from your identity provider | SSO (OIDC) | Team+ |
Private Mode (Password)
Private status pages require a password to view. This is useful when you want to share your status page with a limited audience without setting up SSO.
- Go to Dashboard > Status Pages > [your page] > Visibility and set visibility to Private.
- Enter a password. This is the password your viewers will use to access the page.
- Optionally add a password hint that will be shown on the login screen.
- Save.
When a user visits the status page, they are prompted to enter the password. Authenticated sessions last 24 hours.
Password-authenticated users always receive Full access. Role-based access controls (Full vs Limited) only apply to SSO-authenticated users.
SSO Authentication
Internal visibility (SSO) requires a Team plan or higher. RBAC features require Enterprise. View pricing. Supported Providers
- Google — Google Workspace / Cloud Identity
- Microsoft — Azure AD / Entra ID
- Okta — Okta Workforce Identity
- Custom OIDC — Any provider with a
.well-known/openid-configuration endpoint
Setting Up SSO
- Go to Dashboard > Settings > Access Control and click Add Provider.
- Select your identity provider type.
- Enter your Client ID and Client Secret from your IdP.
- For Okta or Custom OIDC, enter the Issuer URL (e.g.
https://your-domain.okta.com).
- If your IdP uses a non-standard JWT claim name for groups, enter it in the Group Claim Name field (see Custom Group Claim Names below).
- Copy the Callback URL shown in the dialog and register it with your IdP as an authorized redirect URI.
- Click Test Connection to verify OIDC discovery works.
- Save the provider.
Then set any status page to Internal visibility in its Visibility tab.
For Okta, ensure your application’s scopes include groups so that group claims appear in the ID token. This is required for role-based access controls.
Allowed Email Domains
Restrict SSO access to specific email domains. Only users whose email address matches an allowed domain can authenticate.
- Navigate to Dashboard > Settings > Access Control > Allowed Email Domains
- Add domains like
company.com or partner.org
- Leave the list empty to allow any authenticated user from your IdP
Each domain can be assigned an access role (see below).
Role-Based Access Control (RBAC)
RBAC lets you control how much of the status page each viewer can see. There are two roles:
| Role | What the viewer sees |
|---|
| Full | Everything — overall status, service breakdown, SLA targets, uptime graphs, active incident details, past incidents, subscribe form |
| Limited | Overall status banner, active incident count (no details), and subscribe form only |
Assigning Roles via Domains
Each allowed email domain has a role selector. When a user authenticates via SSO and their email matches a domain, they receive that domain’s role.
For example:
company.com → Full — employees see everythingpartner.com → Limited — partners see overall status only
Assigning Roles via IdP Group Mappings
For any SSO provider, you can map IdP group or role claims to access roles. This gives you finer-grained control than domain-level assignment.
- In the SSO provider card, expand the Group Mappings section.
- Enter the exact IdP group name (e.g.
Engineering, StatusPageViewers).
- Choose Full or Limited for that group.
- Save. Users whose ID token contains a matching group claim will receive the mapped role.
By default, group claims are read from standard claim names: groups (Okta), roles (Azure AD), and cognito:groups (AWS Cognito). If your IdP uses a different claim, see Custom Group Claim Names.
Custom Group Claim Names
Enterprise identity providers often use non-standard JWT claim names for group membership. You can configure this per SSO provider.
In the SSO provider dialog, enter your custom claim name in the Group Claim Name field. This supports:
- Simple claim names — e.g.
custom_groups, team_roles
- Dotted paths — e.g.
custom.groups or attributes.roles for nested claims
When a custom claim name is configured, Kodo checks it first, then falls back to the standard claim names (groups, roles, cognito:groups).
Finding your claim name: Log into your IdP admin console, inspect the ID token payload for a test user, and look for the claim containing group membership arrays. Common examples:
- Okta custom authorization server:
custom:groups
- Azure AD app roles:
roles
- Auth0:
https://your-app/roles
Role Resolution Priority
When a user authenticates, their role is resolved in this order:
- IdP group mappings — if any of the user’s groups match a configured mapping, the highest-privilege match wins (
full > limited). Page-specific mappings are checked before organization-wide mappings.
- Domain mapping — if no group mapping matched, use the role assigned to the user’s email domain.
- Default — if neither matched, the user receives Full access.
Access Tokens
Access tokens provide programmatic or automated access to non-public status pages. Use them for CI/CD pipelines, monitoring dashboards, internal tools, or any system that needs to read your status page without interactive login.
Creating a Token
- Navigate to Dashboard > Status Pages > [your page] > Visibility.
- In the Access Tokens section, click Create Token.
- Enter a descriptive name (e.g. “CI/CD Pipeline”, “Grafana Dashboard”).
- Choose an access role: Full or Limited.
- Optionally set an expiry date. Tokens without an expiry remain valid until revoked.
- Click Create Token.
The full token value is shown only once after creation. Copy it immediately and store it securely. You will not be able to view it again.
Using a Token
Append the token as a query parameter to your status page URL:
https://kodostatus.com/status/your-slug?token=YOUR_TOKEN
verify_status_page_access check will validate the token, update its last_used_at timestamp, and grant the configured access role.
Managing Tokens
The Access Tokens table in the Visibility tab shows all tokens for the page:
| Column | Description |
|---|
| Name | The label you gave the token |
| Token | Masked value showing only the last 8 characters |
| Role | Full or Limited access |
| Expires | Expiry date, or “Never” for non-expiring tokens |
| Last Used | When the token was last used to access the page |
Token Best Practices
- One token per integration — create separate tokens for each system so you can revoke independently
- Use expiry dates for temporary access (e.g. a contractor’s dashboard view)
- Use Limited role for external consumers who should only see overall status
- Rotate tokens periodically for long-lived integrations
Session Management
The Active Sessions section in the Visibility tab shows all currently authenticated sessions on your status page. This includes sessions from SSO logins, password authentications, and any other auth method.
Viewing Sessions
Each session row shows:
| Column | Description |
|---|
| Email | The authenticated user’s email (SSO sessions) |
| Method | How the user authenticated: SSO, Password, or Token |
| Role | The access role assigned to this session |
| IP | The IP address the session was created from |
| Login | When the session was created |
| Expires | When the session will automatically expire (24 hours after login) |
Revoking Sessions
- Revoke a single session — click the trash icon on any session row. The user will be prompted to re-authenticate on their next visit.
- Revoke all sessions — click the Revoke All button at the top of the section. This immediately invalidates all active sessions for this status page.
Use session revocation when you suspect compromised credentials, when an employee leaves the organization, or when you change the status page visibility from internal back to public.
Audit Trail
All authentication events are logged to the Audit Log for compliance and security review:
| Event | When it’s logged |
|---|
sso.login_success | A user successfully authenticates via SSO |
sso.login_failed | An SSO attempt fails (bad token, wrong domain, JWKS failure) |
status_page.password_auth_success | A user enters the correct password |
status_page.password_auth_failed | A user enters the wrong password |
access_token.created | An admin creates a new access token |
access_token.revoked | An admin revokes an access token |
Status Pages or Access Tokens.
