Issue
I want to know what happens when I disable a project’s DSN / Client Key - whether that pauses the project, stops events and quota use, what the app sees in the network console, and how long the change takes to apply.
Applies To
All SaaS Customers and Self-Hosted Users
Project Settings
Client Keys (DSN)
Resolution
Disabling a Client Key (DSN) under Project Settings → Client Keys (DSN) stops Sentry from accepting events sent with that key. Those events are dropped and do not consume quota.
This only disables that specific key. If the project has other active Client Keys, events sent with those keys will continue to be ingested. To pause all ingestion for the project, disable every active key (or stop sending events from the SDK).
If the SDK is still running with the disabled DSN, the app will keep trying to send events. Sentry rejects those requests with HTTP 403 and a body like event submission rejected with_reason: ProjectId. This does not affect the app’s functionality; it only results in failed ingest traffic, which is often visible in the browser console.
Config refresh is not always immediate, so expect a short delay before the disable fully takes effect across ingest.
Stopping Events from an Inaccessible Environment
If you need to stop or drop events from an environment you can no longer modify, you can rotate your DSN (Client Key) for the project. This ensures that the old environment cannot send events to your project. Follow these steps:
Navigate to Project Settings > Client Keys (DSN).
Create a new DSN key.
Update your active environments to use the new DSN.
Disable or delete the old DSN key.
By rotating the DSN, you effectively block the inaccessible environment from sending events, ensuring better control over your project’s event flow.
To avoid failed requests entirely, disable or skip SDK initialization in your code instead of only turning off the key. See How do I disable Sentry in specific environments?.
For more information about what a DSN is and how to rotate keys, see the DSN documentation.
Handling Specific Error Events Within an Issue
Sentry does not allow the deletion or isolation of specific error events within an issue. Events are grouped by fingerprints, and separating a subset of events requires unmerging an entire fingerprint into a new issue. This process will include all events under that fingerprint, not just the ones you want to isolate. If you need to evidence the final state of specific events, you can rely on Sentry’s retention policy. Once the retention period expires, the events will no longer exist in the system. Attempting to open the event IDs after this period will confirm their deletion.