Organization Subdomains in DSNs

Every project you integrate with Sentry, and every SDK that you set up has one common bit: the Data Source Name , or in short DSN. It tells the SDK where to find the Sentry server, how to authenticate and which Sentry project to associate your events with.

In an ongoing effort to improve our quality of service, we are extending DSNs with a distinct subdomain for your organization. The new domain name always follows this schema:

o<number>.ingest.sentry.io

The new DSNs compare like this:

Old DSN: https://<key>@sentry.io/4711
New DSN: https://<key>@o42.ingest.sentry.io/4711

When you set up a new project or retrieve an existing DSN, you will see that project settings now shows the new DSN including the subdomain:

Additionally, our documentation pages conveniently display the updated DSN when logged in with your Sentry Account:

What do YOU have to consider?

There is absolutely no action required on your end.

The DSNs you have configured in your existing applications will stay valid. Our servers still operate on the same ip ranges as before. Simply use the new DSNs for any application that you set up for Sentry. Of course, you are free to update existing applications with the new DSNs.

If you have any questions or need help, we have many ways to provide support.

What’s the actual reason for this new configuration style? If it requires no action on the part of the applications reporting, why change at all?

just curious :wink:

Excellent question, @fruitl00p, thanks for asking :slight_smile:

We made this change so that we can optimize for large event volume and enterprise use cases. A few examples of those optimizations include improved traffic routing, rate limiting, and abuse prevention. Ultimately, this gets us closer to maintaining 100% uptime of our ingestion endpoints.

Most of the changes of course happen under the hood in our infrastructure. There are lots of internal improvements planned that will benefit from these new DSNs.

Additionally, we’ve heard cases where users had to proxy traffic through domains other than sentry.io or specifically white list certain endpoints. By moving to a separate domain, we hope that this becomes easier by simply white listing a single domain for all event submission.

1 Like