Skip to content

SaaS administration

Platform administration, organization roles, plan versions, customer branding and MCP keys.

Two administration levels

Open /dashboard for the current organization. Owner/Admin can manage members, invitations, branding, subscriptions and MCP agents. Operators manage monitoring and incidents. Viewers read operational information.

Open /admin with a platform administrator account to search organizations and users, maintain the plan catalog, assign subscriptions, process upgrade requests and inspect audit history. Platform administrator privileges are provisioned through the existing administrative CLI, not a membership role.

A suspended membership loses access to that organization and its OAuth grants. Other organization memberships remain available. Suspending a user revokes all sessions and OAuth grants. Organization suspension stops monitoring and private access; public pages show an unavailable notice, including saved snapshots.

Only Owners may assign Admin roles, modify Admin members or transfer ownership. Ownership transfer requires the current password and an active recipient; the previous Owner becomes Admin.

Plan catalog and subscriptions

Each catalog update creates an immutable version. Existing subscriptions retain their assigned limits and features. Assign the latest version explicitly to change a customer’s entitlement; record a reason, an optional expiry and any contract-specific quotas. The legacy Business quota endpoint remains an adapter to this operation.

The pricing page loads the public, unarchived catalog. Free starts with 10 monitors, 1 page, 3 members/probes/infrastructure resources/MCP agents, 100 metric series, a 60-second minimum interval, 7 days of raw samples and 90 days of aggregates. Business capacity is negotiated and assigned by an administrator; there is no payment checkout.

Owner/Admin can inspect usage and submit an upgrade request from /dashboard/subscription. The request is stored and delivered to CONTACT_EMAIL; platform staff update its processing status and internal note.

Expiry and the Free fallback

The worker checks subscriptions every minute. It sends the current reminder milestone at seven days before expiry, at expiry, and one day before the seven-day grace period ends. Notice records prevent duplicate scheduling. A worker recovering after an outage sends only the current milestone.

After grace, a subscription ends and a new Free subscription starts. Before that date, choose resources to keep from the subscription screen. Include the Owner and every probe assigned to selected monitors. Without a saved selection, the fallback keeps the Owner, then the oldest eligible resources, within Free capacity. All assigned probes must remain available for a monitor to be selected.

Resources over capacity remain stored and are paused. Extra public pages show an unavailable notice. Retained monitors use intervals of at least 60 seconds. Existing samples keep the retention granted when collected; new samples use Free retention. Metric series over quota stop accepting new observations. Upgrade restores eligible resources within the new quota, while monitors manually disabled by a user stay disabled. Keys revoked by quota changes must be reissued.

Customer branding

Create a page at /dashboard/pages, then open /dashboard/branding. Each page has its own draft and published identity: name, description, logo, favicon, accent, theme and website link. Desktop/mobile previews use a clearly labelled sample status layout. Save a draft or publish it when ready.

Upload PNG, JPEG or WebP files up to 2 MiB and 16 megapixels. The API decodes and normalizes images to PNG, resizing large images to 2048 pixels on the longest side. SVG, HTML and custom CSS are not accepted. Draft images are private; publication copies them to immutable public objects. Only published identity enters the public API and saved status snapshots.

Customer pages live at /status/{slug}. Their header, title and favicon use the customer identity. The provider footer remains Powered by Nextvision AI. Custom hostnames are not configured in this release.

MCP agent keys

Open /dashboard/mcp-agents to create an organization-owned agent. Its default scope is status:read; grant incident:draft when needed. Each key is shown once and stored only as a SHA-256 hash. Validity options are 30, 90 (default) or 365 days.

Send the key only in an authorization header:

Authorization: Bearer <MCP_API_KEY>

For the local stdio adapter:

MCP_URL=https://status.example.com/mcp
MCP_API_KEY=<secret-from-your-secret-store>
./mcp-stdio

MCP_ACCESS_TOKEN remains supported for OAuth access tokens. Never put a key in a URL or commit it to a client configuration repository. Rotating revokes the old key immediately; disabling an agent revokes all its keys. Re-enabling requires a newly issued key.

Usage shows the last actual tool call, call/error counts and recent tool names. These are activity observations, not proof of a permanently connected agent. Each identity is limited to 240 MCP HTTP requests per minute. Keys cannot authenticate to the REST management API. Agent scopes do not include publishing, monitor changes or remediation.

OAuth discovery and PKCE continue to serve clients using the MCP authorization specification. Direct keys are a separate product authentication option; clients must support sending the configured header.

Upgrade and rollback

Back up PostgreSQL and MinIO before changing versions. Run migrations first, then roll out and verify all API/worker/delivery replicas before updating the frontend and docs. During the first upgrade from v1.0, keep administration changes paused until every backend replica runs v1.1; mixed versions do not share the new suspension and retention semantics. With Helm, promote the backend digest first while retaining the previous web/docs digests, wait for those backend rollouts, then promote the new web/docs digests. The migration backfills existing subscriptions with their current quotas, including custom Business agreements. New tables enforce tenant row-level security. Do not roll back database migrations by deleting subscription history or brand assets; use a compatible application release and restore from a verified backup when necessary.

Type to search…

↑↓ navigate↵ selectEsc close