All features
Governance

Environments: separate production, staging and dev monitoring and access

Staging noise shouldn't page production on-call, and a developer's API key shouldn't be able to touch production monitors. Environments tag every monitor, credential and API key, and API keys can be restricted to the environments they may act on.

Create the environments your organization actually has — production, staging, dev, per-customer — and assign monitors to them. Alert destinations and incident rules can then differ per environment, so staging posts to a channel while production pages.

On the access side, an API key or service account can be limited to specific environments; a CI pipeline that creates staging monitors physically cannot create or delete production ones.

  • Per-environment alerting and incident rules.
  • Environment-restricted API keys enforced server-side.
  • Filters everywhere — monitors, incidents and reports by environment.
mcp · connected clients
claude-desktop
scopes: monitors:read · incidents:read
Active
ops-copilot
tool call · list_incidents(status=open)
Policy-gated
runbook-agent
requires approval to acknowledge
Approved

How it works

  1. 1Define environments under Developer & API → Environments.
  2. 2Assign monitors, credentials and destinations to an environment.
  3. 3Restrict API keys and service accounts to the environments they need.

Plan availability

Pro and above (RBAC roles · credential vault · environments).

Compare plans →

Monitor types that use it

Questions about environments

Can a monitor belong to more than one environment?
No — one environment per monitor keeps the access rules unambiguous; use groups or tags for cross-cutting views.