Issue
I want to know why events from development or staging reopen a production issue I already resolved.
Applies To
All SaaS Customers
Issue grouping / environments
Symptoms
Unexpectedly regressed Issues
Unexpected Alerts- Regression alerts failing to fire due to environment-specific configurations, where an issue regresses in a non-target environment and does not trigger alerts in the target environment.
Resolution
Yes, that’s expected. Issues are shared across environments by default. The default issue grouping does not include the environment, so a matching event from another environment can be grouped into the same issue and may cause it to be marked Regressed.
This can also affect alerts. For example, if a regression alert is scoped specifically to production, a regressing event from staging won’t trigger that alert, even though the shared issue itself may already be marked as regressed.
To keep environments separate going forward, you have two options:
Fingerprint by environment
Go to Project Settings → Issue Grouping → Fingerprint Rules and add a rule for each environment you want to isolate:tags.environment:development -> {{ default }}, {{ tags.environment }} tags.environment:staging -> {{ default }}, {{ tags.environment }}This preserves Sentry’s default grouping while adding the environment to the fingerprint, so matching events from different environments are grouped into separate issues. Add a separate rule for each environment you want to isolate.
Use separate Sentry projects per environment
This provides full isolation between environments, including separate issues, alerts, quotas, and project settings.
One important limitation: fingerprint rule changes only apply to new events. Existing events and issues will not be regrouped retroactively.
For more information, see Fingerprint Rules and Environments.