> ## Documentation Index
> Fetch the complete documentation index at: https://sentrydocs.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 theme={null}
// JavaScript / Node.js
Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  environment: "production",
});
```

```python theme={null}
# Python
import sentry_sdk

sentry_sdk.init(
    dsn="https://examplePublicKey@o0.ingest.sentry.io/0",
    environment="production",
)
```

```javascript theme={null}
// React Native
Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  environment: process.env.APP_ENV ?? "development",
});
```

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

## 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

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

## 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.