If your Sentry integration is timing out, showing "unable to connect" in the issue link modal, or producing no traffic on your server despite an IP allowlist being in place, you are most likely missing a newer set of control silo IP addresses that are absent from many allowlists configured before 2026.
Who this applies to: this matters for any integration where Sentry needs to reach something behind your own firewall. A self-managed tool (e.g. GitLab self-managed, GitHub Enterprise, Perforce, an on-prem Jira Server/Data Center, etc.), a custom Integration Platform app, or your own server hosting JavaScript source maps.
Note: It does not apply to purely cloud-hosted integrations (Slack's cloud API, GitHub.com, GitLab.com). Sentry reaches those over the public internet with nothing of yours in between to allowlist.
Control silo IPs
Add the following addresses to your server or firewall's outbound-facing (inbound to you) allowlist:
35.222.255.47/32
34.61.215.243/32
34.71.103.17/32
For the full list of standard outbound IPs (US and EU), see Sentry's IP Ranges documentation: https://docs.sentry.io/security-legal-pii/security/ip-ranges/. Even if your organization uses EU data storage, include the US ranges. Integration metadata is processed in the US region.
Staying current as IPs change
Sentry publishes current IP ranges at:
https://docs.sentry.io/api/ip-ranges
For integrations, watch all three keys: outbound_requests.control, outbound_requests.us, and outbound_requests.eu. If you automate this, there are a couple of general best practices to follow:
Read region keys by name (e.g.
outbound_requests.us), not by position. This ensures that adding new regions, in the future, won't break your parser.Treat a non-200 response or empty array as a failed fetch, not an empty list. Acting on an empty result could wipe your allowlist.
Related
Sentry IP Ranges documentation: https://docs.sentry.io/security-legal-pii/security/ip-ranges/
Machine-readable IP ranges API: https://docs.sentry.io/api/ip-ranges