Settings

Everything under the console’s Settings page, one section per tab: the workspace itself, its API keys, the organization and its members, and the shared views that leave it.

A Rius workspace is where your traces live. Every trace your SDK or collector sends belongs to exactly one workspace, determined by the API key it authenticates with. The workspace switcher sits at the top of the sidebar; everything you see in the console (traces, agents, keys, settings) is scoped to the selected workspace.

Workspace

Settings → Workspace shows the workspace’s name and ID. Admins can rename or delete the workspace; members see the name and ID only:

API keys

API keys authenticate ingest, requests to https://ingest.eu.console.rius-glassflow.com (the SDK’s default endpoint). Each key belongs to one workspace: traces sent with it appear there and nowhere else. Create keys from Settings → API keys or from the Get started page:

Only admins create and revoke keys. Members see the key list, which carries names and prefixes but no secret material.

A key carries the capabilities you pick when you create it. Send telemetry (ingest), the default, is what the SDK needs. Query data (read) lets the key read traces and metrics and connect an MCP client; a key with both scopes serves an agent that ships its own traces and queries them. Two further scopes, alerts:manage and channels:manage, let a headless agent manage alerting; they are minted only from the MCP page’s Connect an agent dialog, see headless connections.

Keys start with ri_. Keys minted before the prefix change start with gf_ and keep working; there is no need to rotate them for the prefix alone.

A key can carry an expiry, chosen when it is created: 30 days, 90 days, one year, or never, which is the default. The key list shows each key’s expiry and marks keys that are about to expire and keys that have expired. An expired key fails authentication exactly like a revoked one, so treat expiry as a scheduled rotation: mint the replacement before the date, move your agents over, and let the old key lapse.

A key is shown in full exactly once, when it is created; afterwards the console keeps only its name and prefix, and the server stores only a hash. Lose a key and the path is revoke and reissue, there is no recovery. Revoke takes effect immediately: in-flight traffic with a revoked key starts failing authentication right away, so rotate by creating the new key first, moving your agents over, then revoking the old one. The one exception is an MCP client already connected with the key, which can keep working for up to a minute because the MCP server caches key validation briefly.

Organization and members

Workspaces, members, and invitations belong to the organization; it spans every workspace you are a member of. Settings → Organization shows the organization’s name, your role, and the member list:

Inviting a teammate sends them an email with a one-time link to join. The invitation carries the role the new member will hold. Invitations expire after 7 days; accepted and revoked invitations leave the pending list.

Inviting, revoking pending invitations, changing a member’s role, removing a member, and renaming the organization are admin actions. Members see the member list and their own role.

Roles and permissions

Every member holds one of two roles in the organization. Roles are per organization: a user who belongs to several organizations can be an admin in one and a member in another.

• Admin manages the organization and its workspaces: members, invitations, API keys, alerting configuration, and the workspaces themselves. Admins always have access to every workspace in the organization.
• Member works with the telemetry: explores traces and agents, follows usage and cost, acknowledges firings, shares views, and connects MCP clients. Members cannot change how the organization or its workspaces are configured.

Roles and workspace access are separate settings. A member reaches either every workspace in the organization, the default, or only the workspaces an admin picks for them; admins change this per member from the member list, with Specific workspaces.

The console hides the controls a member cannot use, and the API answers 403 Forbidden if they are called anyway.

An organization always keeps at least one admin: the last admin cannot be demoted to member or removed. Promote someone else first.

API keys can carry the alerts:manage and channels:manage scopes, which let an MCP client or automation manage rules and channels the way an admin does. See headless connections for using a key with an MCP client.

Root-cause analysis

The Intelligence section of Settings → Workspace controls whether alert firings in this workspace are handed to an analysis agent, powered by Tares, that investigates the affected traces and writes a report back onto the firing page. The section shows the state of the workspace’s analysis cell and lets an admin pause and resume it. While paused, alert context is still stored, but no analysis runs.

Per alert, the Root-cause analysis switch on the alert’s page decides whether that alert’s firings are sent; see Alerts.

Shared views

A shared view is a public link to a frozen window of traces, created with Share from the trace list. It freezes the time range and the status filter that were active, so a link created from a failed-only view stays failed-only, and it expires after 24 hours, 7 days, or 30 days, whichever you picked. Any member can create and revoke shared views, not only admins. Anyone with the link sees metadata and rollups until it expires or you revoke it in Settings → Shared views. Links themselves are shown only at creation, the same rule as API keys:

The recipient opens a read-only page scoped to exactly that window: the rollups, the trace list, and nothing else of the workspace.

Next steps

• Installation and configuration: where the API key goes in the SDK.
• Exploring traces: the view a shared link freezes.