Environments

Filter and manage Sentry data across production, staging, and development environments.

Environments let you separate data from different deployment stages within a single Sentry project. You can filter the issue stream, performance data, and alerts to only show events from a specific environment like production, staging, or development.

How environments work

An environment is a tag attached to every event your SDK sends. When you set the environment option in the Sentry SDK, all events from that instance are tagged with that environment name. Sentry then lets you filter any view by environment.

Environments are scoped to your organization — if two projects both send events tagged production, they share the same production environment at the organization level.

Setting the environment in your SDK

Configure the environment when you initialize Sentry:

// JavaScript / Node.js
Sentry.init({
  dsn: "https://[e-mail]/0",
  environment: "production",
});

# Python
import sentry_sdk

sentry_sdk.init(
    dsn="https://[e-mail]/0",
    environment="production",
)

// React Native
Sentry.init({
  dsn: "https://[e-mail]/0",
  environment: process.env.APP_ENV ?? "development",
});

Read the environment from a runtime variable rather than hardcoding it. This lets you deploy the same build to different environments without changing code.

Filtering by environment in the UI

The environment selector appears at the top of most Sentry views. Selecting an environment filters:

• The issue stream
• Issue event counts and graphs
• Performance data
• Release health metrics
• Dashboards

You can select a single environment or view All Environments to see combined data.

Environment-specific alert rules

Alert rules can be scoped to a specific environment. When you create an issue alert or metric alert, you can optionally restrict it to fire only for events from a chosen environment. This means you can have a high-urgency alert for production and a lower-priority alert (or no alert at all) for staging.

To set an environment on an alert:

1. Go to Alerts → Create Alert
2. In the alert configuration form, find the Environment field
3. Select the environment this rule should apply to

If you leave the environment field blank, the alert applies to events from all environments.

Hidden environments

If you send events to Sentry from environments like local, test, or ci, the environment list can become cluttered. You can hide an environment so it doesn’t appear in the environment selector by default.

To hide an environment:

1. Go to Settings → Environments
2. Click the environment you want to hide
3. Toggle Hide from project filters

Hidden environments still receive and store events — they’re just excluded from the environment dropdown to reduce noise.

Best practices

• Use consistent names across your SDK deployments. production, staging, and development are conventional names. Avoid variations like prod, PRODUCTION, or Production, which Sentry treats as separate environments.
• Avoid environment names that change per-deploy (e.g. a commit SHA). Environments are organization-wide and a new name creates a new environment record every time.
• Scope production alerts tightly by setting environment: production on your most critical alert rules, so staging noise doesn’t page your on-call team.