Manage your workspace

A workspace is the tenant boundary. Everything captured, every key, every member and every alert belongs to exactly one, and nothing crosses between them. Workspace administration lives on the Organization page, and keys on the Keys page.

Roles

There are three, and a person has exactly one.

	owner	member	viewer
See every dashboard page, traces included	Yes	Yes	Yes
Create and revoke ingest keys	Yes	Yes	No
Acknowledge alerts	Yes	Yes	No
Create, cancel and schedule datasets	Yes	Yes	No
Change route configuration	Yes	Yes	No
Approve a recommendation for delivery	Yes	Yes	No
Rename the workspace	Yes	No	No
Invite people	Yes	No	No

A viewer is a genuine read-only role: they can see captured content in the Traces page like anyone else, but every write is refused with a 403.

Invite someone

1. Send the invitation

   On the Organization page, an owner enters an email address, an optional display name, and a role of member or viewer. There is no way to invite a second owner.

2. They get an email

   Invitations go out through the identity provider’s temporary-password flow. The new member appears in the member list with the status invited straight away, and becomes active once they sign in.

3. Resend if it does not arrive

   Re-inviting the same address resends. If the member row was saved but the email failed, the API says so explicitly rather than silently succeeding, and resending is the fix.

Roles and membership are one-way today

There is no control, in the dashboard or the API, to change someone’s role or to remove them from a workspace. Invite carefully: an invitation sent as member cannot later be downgraded to viewer, and someone who leaves your company keeps their access until an operator intervenes. Ask Metergraph if you need a member removed.

Rename the workspace

Owners only, 2 to 100 characters. The slug does not change with it: the slug is the workspace’s stable identifier and stays as it was created.

API keys and scopes

The Keys page mints ingest keys: mg_ followed by 48 hex characters, shown once at creation and stored only as a hash afterwards. Name each one for where it runs, production, ci, laptop, because the list afterwards shows only a label, a first-and-last hint, and whether it is revoked. Revoking is immediate and cannot be undone; mint a new key rather than trying to restore one.

Every key the dashboard creates carries the ingest scope and only that scope. That is enough to send rows and to exchange a session token, and not enough for anything else.

Scope	What it opens	How you get one
ingest	POST /v1/ingest, POST /v1/traces, POST /v1/ingest/sessions	The Keys page
read	The reporting endpoints, including GET /v1/alerts	Operator command line only
agent:read	/v1/agent/routes and /v1/agent/traces for the MCP server	Operator command line only

Two of the three scopes are not self-serve

read and agent:read keys can only be issued with the operator command line, which runs with database access inside the deployment. If you run Metergraph yourself, that is your own command. On the hosted service it is a request to Metergraph. See Use the MCP server.

Dashboard endpoints, including everything on the Organization page, are authenticated by the browser session rather than by a key. No API key of any scope can drive them.

Environments

An environment is not something you create in the dashboard. It is a label the SDK stamps on every row, and the dashboard offers whichever labels it finds.

.env

METERGRAPH_ENV=production

Or in code, init(environment="production"). Anything you like: production, staging, a preview branch name. Keep the spelling stable, because detectors build a route’s baseline within one environment, and a rename starts that baseline again from nothing.

Rows sent without an environment are not lost. The environment filter lists the non-empty environments seen in the window you are looking at, and selecting none of them means all traffic, including calls that never carried a label.

The monthly allowance

A workspace on the free plan is allowed 100,000 captured calls per month. The period is the calendar month in UTC, and the counter resets on the first. Calls are counted as they are stored, so a batch that is accepted counts when the worker writes it.

Where you are	What happens
Under 80%	Nothing, other than a meter on the Get started page
80% or more	A banner on every page with the count and the allowance
At the allowance	POST /v1/ingest answers 402 with the code quota_exceeded, and capture pauses

A 402 is not a client error you can retry your way out of. The SDK treats it as a transient server condition: it backs off, doubling up to 60 seconds, and the rows queued in the meantime are dropped. Your application keeps working normally, because capture never sits in the request path. Nothing is billed and nothing is stored until the next period or a larger allowance.

The dashboard’s upgrade button records an upgrade request that a person follows up on. There is no self-serve plan change, and no card entry in the product.

Separately from the allowance, captured metadata is retained for 90 days.

Limits and allowances Every limit in one table, with the source that sets it.

See also

• Send your first trace
• Set up alerts
• Write your own client for what a 402 looks like on the wire