Atlassian cloud adds new IP ranges on 1 January; update your allowlists
EditorialBy TrustList Editorial
Firewalls that allowlist Atlassian by address must add 131.162.88.0/23 for traffic to Atlassian and 131.162.90.0/23 for webhooks and app calls from it, or integrations may break when the ranges go live.
About Atlassian cloud adds new IP ranges on 1 January; update your allowlists
Atlassian cloud adds new IP ranges on 1 January; update your allowlists
16 October 2026: Atlassian cloud will start using a new block of IP addresses, 131.162.88.0/21, from 1 January 2027 as it expands its infrastructure. Any app, backend or integration that allowlists Atlassian's addresses has to add the new ranges before then "to avoid service interruptions", the company says.
Not yet independently verified. Rests on Atlassian's Jira Cloud platform changelog; we did not check the matching Confluence and Bitbucket changelogs. We will update this when it can be confirmed, and remove this note.
The new ranges
The new /21 is split by direction of traffic:
| Direction | Range |
|---|---|
| Requests to Atlassian (browsers and clients calling Atlassian APIs) | 131.162.88.0/23 |
| Requests from Atlassian (webhooks, Connect lifecycle calls and other calls to your app) | 131.162.90.0/23 |
The ranges are added to the existing ones, not swapped for them, so nothing should be removed. Atlassian says they are already in its official IP range list, so teams that update allowlists automatically from that file need do nothing.
Outbound firewalls and inbound webhooks
The change matters in two directions. Companies that restrict outbound traffic from their own networks, through corporate firewalls, proxies or zero-trust gateways that only permit known destinations, need the first range so that users and scripts can still reach Jira, Confluence and Atlassian's APIs. Developers and integration owners who accept inbound traffic only from Atlassian's addresses, for webhooks, Connect app lifecycle events or calls from automation rules, need the second range, or events will be silently dropped once Atlassian starts sending from it.
The second case is the easier one to miss. A webhook receiver behind a cloud firewall, a self-hosted CI server that Jira automation calls, or an on-premises integration exposed only to Atlassian can all fail without any error showing in Atlassian's own interface.
Getting ready before January
The safest route is to stop maintaining the list by hand and pull it from Atlassian's published IP range file on a schedule, which Atlassian's documentation on IP addresses and domains for cloud apps describes. Where that is not possible, network teams should add both /23 ranges now and test inbound webhooks before the holiday change freezes that many companies run in late December. Atlassian is headquartered in Sydney, and its Jira and Confluence cloud products sit in our DevOps software category, which lists 16 products.
Sources
Categories & features
TrustList Weekly
The week in software and IT, in one email
The news that matters to buyers, new rankings and our own research. Every Thursday, free, and easy to leave.
More on TrustList
Everything here links back to the same verified catalogue. Pick your next stop.
- More AustraliaThe ranking for this subject
- CompaniesAgencies, consultancies and IT service providers, ranked by verified reviews.
- ProductsSoftware and SaaS with pricing, features, integrations and alternatives.
- AwardsAnnual recognition decided by verified reviews and an independent jury.
- LaunchesNew products and releases, voted up by the community every day.
- AI ModelsBenchmark scores and community ratings for every major model.
- RequestsBuyers describe what they need; vendors respond directly.
- PeopleReviewers, authors and makers with public profiles.
- ComparePut up to four listings side by side before you shortlist.