If your webhook receiver sits behind a firewall, there's probably a list of Atlassian IP addresses pasted into it somewhere, and on 1 January 2027 that list goes out of date. On 16 October Atlassian posted an announcement to its developer changelog saying its cloud adds 131.162.88.0/21 to the IP ranges it already uses. Calls from Atlassian to you (webhooks, Connect lifecycle calls and "other requests from Atlassian to your app") can come from 131.162.90.0/23, and calls to Atlassian can go to 131.162.88.0/23.
This change only adds ranges (Atlassian says they're "in addition to our existing ones"), so nothing stops working before January. After that, a firewall without the new block will drop whatever webhooks Atlassian sends from it. When I tested our own site on 29 October, 0 of 12 requests came from 131.162. And Atlassian's IP addresses and domains page still says "These addresses were last updated on April 3, 2025" near the top, even though the new block is already in its lists further down. So it's easy to read the page and think nothing moved.
Most teams will be fine, I think. They add one /23 to one rule. You get caught if you add the wrong half, or if you type in 131.162.0.0/16 because it looks tidier.
What we found in the list, the owner records and our own webhooks
- Atlassian put the 131.162 entries in its machine-readable list by 12 October, before the announcement, and they weren't there in January.
- Atlassian's word "egress" means your inbound. Your webhook firewall needs 131.162.90.0/23.
- Atlassian registered 131.162.88.0/21 and no other part of that /16. A university owns one of the neighbouring blocks.
- Webhooks and Automation on the same site left from two different AWS regions within one minute. Automation used IPv6 for one of its two calls.
- Email, Bitbucket, Trello, Opsgenie and Statuspage have no 131.162 entry at all. Atlassian's notification mail doesn't change.
- Atlassian Administration's IP allowlist is a different list. It decides who can reach your Jira. Atlassian's own addresses only go in it as a workaround, when Automation calls back into your own site.
What changes on 1 January 2027 in the Atlassian cloud IP ranges
Atlassian titled the changelog entry "Atlassian cloud will start using new IP address ranges as we expand our cloud infrastructure", and it's copied into eight product changelogs, Rovo MCP's and Compass's among them. This is the sentence to send your network team:
From January 1, 2027, Atlassian cloud will add new IP address ranges as we expand our cloud infrastructure. The new ranges are in addition to our existing ones.
It then splits the /21 in two. "Requests to Atlassian (browsers and your clients calling Atlassian APIs): 131.162.88.0/23." And "Requests from Atlassian (webhooks, Connect lifecycle calls, and other requests from Atlassian to your app): 131.162.90.0/23." The instruction is to add them before 1 January 2027, and "If you automate your allowlist updates from this file, no further action is required."
You'll find the file at ip-ranges.atlassian.com. When we read it on 30 October it had syncToken 1793068228, a creationDate of 27 October, and 173 prefixes. Four of them are new:
$ curl -s https://ip-ranges.atlassian.com/ > ip-ranges.json
$ jq -r '.syncToken, .creationDate, (.items|length)' ip-ranges.json
1793068228
2026-10-27T02:30:28.885679
173
$ jq -r '.items[] | select(.cidr|startswith("131.162."))
| [.cidr, (.direction|join(",")), (.product|join(","))] | @tsv' ip-ranges.json
131.162.90.20/30 egress rovo-crawler
131.162.88.0/21 egress,ingress confluence,forge,jira,loom
131.162.90.0/23 egress confluence,forge,jira,loom
131.162.88.0/23 ingress confluence,forge,jira,loom
The /23 marked egress is the one your webhook firewall needs, and the /30 for the Rovo crawler sits inside it.
The changelog and the JSON don't list the same products for the block. In the JSON the block is tagged for four (Jira, Confluence, Forge, Loom). In the changelog it's REST APIs (Jira, Confluence, Cloud Admin, Opsgenie), GraphQL (Compass, Confluence, Jira), Forge and Rovo MCP, and it never mentions Loom. Opsgenie has no 131.162 entry in the file at all. If you allowlist per product, I'd go by the file, because it's the thing Atlassian tells you to automate from.
The new block was in the file before the announcement
I found two copies of the file from this year in the Wayback Machine. A January one (26 January, syncToken 1768869839) has 253 prefixes and none under 131.162. An October one (12 October, syncToken 1791782645) already has all four entries, with the same fields as today. So the block went in somewhere between 20 January and 12 October. ARIN's record says Atlassian registered it on 13 April. Since 12 October only three new Bitbucket /32s in eu-central-1 have appeared.
If your firewall list was copied in January, it's stale in more ways than this one. Between that copy and today, 92 prefixes left the file (88 of them Forge egress /32s) and 12 came in.
Inbound vs outbound: which half of 131.162.88.0/21 your firewall needs
Atlassian names directions from its own side. Its support page defines an egress connection as "one made by an Atlassian app or service to a server on the internet on your behalf", and lists webhooks, application links to on-premise servers and "checking for new emails on an email server" as examples. Ingress is the other way, "a client, such as a browser, script, app, or SSH client" calling Atlassian. So egress in their file is inbound on your firewall. It's easy to flip this when the rule you're editing is called "inbound".
| What you run | Atlassian's term | Rule on your side | Add from 131.162 |
|---|---|---|---|
| Webhook receiver for Jira or Confluence | egress | allow inbound from Atlassian | 131.162.90.0/23 |
| Endpoint called by Automation "Send web request" | egress | allow inbound, IPv4 and IPv6 | 131.162.90.0/23 |
| Forge Remote backend behind a firewall | egress | allow inbound | 131.162.90.0/23 |
| Connect app server (lifecycle calls, webhooks) | egress | allow inbound | 131.162.90.0/23 |
| On-prem server reached by application links, or a mail server Jira reads from | egress | allow inbound | 131.162.90.0/23 |
| Corporate proxy or egress firewall that limits where staff can browse | ingress | allow outbound to Atlassian | 131.162.88.0/23 |
| Scripts or CI calling Atlassian APIs through a destination-filtered firewall | ingress | allow outbound to Atlassian | 131.162.88.0/23 |
Atlassian's page says that "most admins operating allowlisting systems (such as firewalls, access control lists, and security groups) are only interested in the IP ranges Atlassian apps use to make outgoing connections". That's the first five rows. If you'd rather add the whole /21 to both, the page's own "Atlassian summary IPv4 ranges (preferred)" list now ends with 131.162.88.0/21, so you'd be matching Atlassian's own summary.
The page also says not to allowlist by region ("include all networks relevant to an app and direction"), and that "Atlassian apps may connect using either IPv4 or IPv6." Our test below hit both.
Atlassian owns the /21 and nothing around it
A /21 is 2,048 addresses, 131.162.88.0 to 131.162.95.255. ARIN's record for it is NET-131-162-88-0-1, a direct allocation to Atlassian Network Services, Inc., registered on 13 April 2026. Other people own the blocks around it: 131.162.8.0 to 131.162.87.255 is Acadia University, 131.162.96.0 to 131.162.111.255 is registered to Joe Wheeler EMC, and 131.162.0.0/22 is registered to someone else again. So please don't round it up. A rule for 131.162.0.0/16 would let the university's network talk to your webhook receiver.
Mihai's piece on Atlassian Cloud edge security names the two netblocks Atlassian already sends from, 104.192.136.0/21 and 185.166.140.0/22. This is a third one.
Jira webhook IP ranges and Automation "Send web request": what our test site sent
I wanted to see where these calls come from today, before the new block is used. On 29 October I made a free receiver on webhook.site and pointed two things at it from our test site, wolfaenpak.atlassian.net. One was a Jira admin webhook, created through POST /rest/webhooks/1.0/webhook for issue created and issue updated in one test project. The other was an Automation rule with one "Send web request" action that fires when an issue is created. Then I created three test issues and edited one of them seven times.
# 12 requests to our test receiver, 29 Oct 2026, from wolfaenpak.atlassian.net (UTC)
time source IP sender event
22:44:21 185.166.142.241 Atlassian Webhook HTTP jira:issue_created
22:44:27 185.166.142.240 Atlassian Webhook HTTP jira:issue_updated
22:46:47 185.166.142.248 Atlassian Webhook HTTP jira:issue_created
22:46:49 104.192.142.248 Automation for Jira automation
22:47:02 185.166.142.241 Atlassian Webhook HTTP jira:issue_updated
22:47:02 185.166.142.241 Atlassian Webhook HTTP jira:issue_updated
22:47:03 185.166.142.242 Atlassian Webhook HTTP jira:issue_updated
22:47:03 185.166.142.241 Atlassian Webhook HTTP jira:issue_updated
22:47:04 185.166.142.241 Atlassian Webhook HTTP jira:issue_updated
22:47:05 185.166.142.242 Atlassian Webhook HTTP jira:issue_updated
22:47:05 185.166.142.242 Atlassian Webhook HTTP jira:issue_created
22:47:07 2401:1d80:321c:5:e21c:bcb1:22a4:ba47 Automation for Jira automation
# requests from inside 131.162.90.0/23: 0 of 12
Look at the two Automation lines: same rule, 18 seconds apart, one IPv4 and one IPv6, both from a different region than the webhooks.
Ten webhook deliveries came from 185.166.142.240, .241, .242 and .248. All four sit in 185.166.142.240/28, which the file tags as egress for eu-west-1. Both Automation calls came from us-east-1: 104.192.142.248 (inside 104.192.142.240/28) and 2401:1d80:321c:5:e21c:bcb1:22a4:ba47 (inside 2401:1d80:321c:5::/64). Their user agent was "Automation for Jira AC app/1.0". None of the 12 came from 131.162.90.0/23. That fits a start date of 1 January.
So in about three minutes, one site used two regions and both IP versions. It's a small sample from one site, but a rule that lists only the few Atlassian addresses you've seen in your logs would already have missed some of these. Check your IPv6 rules. If your endpoint has an IPv6 address (an AAAA record) and your firewall has no IPv6 rule for Atlassian, Automation calls like the second one would already be hitting it.
I couldn't find a support page just for Automation's outgoing IPs (the URL you'd guess returns a 404). Atlassian's webhooks documentation only says "You need to allow-list IP address ranges for outgoing connections to ensure webhook delivery", which sends you back to the same list.
When I was done I deleted the webhook (the GET after it returned 404), the Automation rule, the three issues and the webhook.site token, so the test site is back to how it was.
Forge remotes and Connect apps: what your backend must allow
Forge remotes and Connect app servers need 131.162.90.0/23 too. Forge's Remote essentials page says: "When communicating with remote backends, Forge uses IP address ranges as indicated in the Outgoing Connections section". Forge is one of the four products tagged on the 131.162 entries, so a remote behind a firewall needs 131.162.90.0/23 like any webhook receiver. Connect is named too. "Connect lifecycle calls" are in the changelog, so a Connect app server needs the same /23 for its install and uninstall callbacks.
The support page also warns that these outgoing ranges "include traffic that is untrusted and user-configurable, for example the Forge platform." Anyone can write a Forge app. Its fetches leave from the same Atlassian addresses. An allowlist tells you a request came from Atlassian's network. It doesn't tell you which customer or which app sent it, so your backend still has to check the JWT or the signature on every call.
For Connect apps the new range starts a month before Connect end of support on 31 January 2027. If you're still running a Connect app server in January, it needs the new /23 from 1 January and for as long as it keeps running after that.
Email, Bitbucket Pipelines and the Rovo crawler IP ranges: only the crawler gets a 131.162 entry
Email isn't affected. In the file 24 entries are tagged email. They match the support page's list of notification senders exactly (I diffed them), and not one is a 131.162 address. Email has had its own moves before. In May 2025 Atlassian posted Atlassian emails will be coming from new ips (4,213 views), and in August a follow-up, Atlassian emails - IP range changes, which has 3,111 views and no comments. Both of those ranges are still in the email list.
One mail rule does change. If Jira or Jira Service Management reads mail from your own mail server, Atlassian counts that as egress ("checking for new emails on an email server"), so that server's firewall needs 131.162.90.0/23 like a webhook receiver does.
Bitbucket has 100 entries in the file, with no 131.162 among them. Its firewall page sends you to the same JSON and to the Outgoing Connections list for webhooks. Pipelines runner IPs are a separate list. Trello would rather you didn't use IPs: its firewall page says "Trello's IP addresses can change frequently and without notice" and suggests domain names instead. Opsgenie and Statuspage are in the file too. Neither has a 131.162 entry.
Rovo's crawler has its own 131.162 entry: 131.162.90.20/30, egress, in gcp-us-central1. It's the only 131.162 entry with a region that isn't global, and it sits inside the egress /23. If you let Rovo's crawler into an internal site you've connected, check that the /30 (or the /23) is in that rule. The support page lists 14 crawler ranges and the file has 13. The page's extra one, 104.192.138.224/28, left the file this year.
Loom is tagged on all three big 131.162 entries in the file, but Loom's own domains and ports article only lists domains and points you to AWS's published ranges. If your proxy restricts Loom by IP, I'd add 131.162.88.0/23 for it too.
Atlassian Guard IP allowlist is a different list from your firewall
In Atlassian Administration, under Security, Device security, IP allowlists, you can create a list of the addresses your people must use to reach Jira or Confluence. The page says "Powered by Atlassian Guard", but the plan Atlassian's doc asks for is the app's: Premium for Jira, Jira Service Management, Confluence and Compass. An org admin sets it up. Atlassian's docs put it this way: "Use an IP allowlist to specify which IP addresses or locations users must use to access content".
That list is about your users' addresses, so for most orgs the 2027 change needs nothing there. Where the two do meet is when Atlassian calls itself. A thread on the developer community, Jira Cloud IP Allowlisting and Automation Web Request (2,277 views), describes an Automation rule that calls its own site's REST API and fails once the allowlist is on. A request to exclude Atlassian's own IPs automatically, ACCESS-1002, has 34 votes and is still gathering interest. Its workaround is to add Atlassian's IPs to the allowlist by hand. If you did that, add 131.162.90.0/23 there too before 1 January, or the Automation calls that leave from the new block get rejected. If you use Guard together with data security policies, it's a good moment to re-check which rules call back into your own site.
Atlassian IP allowlist from the ip-ranges.atlassian.com JSON: a script you can schedule
Atlassian's line is that if you build your allowlist from the file, you don't need to do anything. So I'd stop pasting the list by hand. I ran this small script on a Mac on 30 October. It downloads the file, keeps every egress prefix tagged for Jira, Confluence or Forge (IPv4 and IPv6), and prints what was added or removed since the last run, using the syncToken to tell whether anything changed. The Automation addresses from our test sit in prefixes tagged jira, so this filter covers them:
#!/usr/bin/env bash
# Builds the list of CIDRs that Jira, Confluence and Forge call your servers from,
# and tells you what changed since the last run. Needs curl and jq.
set -euo pipefail
curl -sf https://ip-ranges.atlassian.com/ -o ip-ranges.json
token=$(jq -r .syncToken ip-ranges.json)
last=$(cat last-token.txt 2>/dev/null || echo none)
jq -r '.items[]
| select(.direction | index("egress"))
| select(.product | any(. == "jira" or . == "confluence" or . == "forge"))
| .cidr' ip-ranges.json | sort -u > allow-new.txt
if [ "$token" = "$last" ]; then
echo "no change (syncToken $token)"
else
echo "syncToken $last -> $token"
touch allow.txt
comm -13 allow.txt allow-new.txt | sed 's/^/add /'
comm -23 allow.txt allow-new.txt | sed 's/^/remove /'
mv allow-new.txt allow.txt
echo "$token" > last-token.txt
fi
wc -l < allow.txt | xargs echo "prefixes in allow.txt:"
On the first run it prints all 96 prefixes as adds (39 IPv4 and 57 IPv6), with the two new ones among them. When I ran it again straight away, it only reported that nothing changed:
$ ./atlassian-egress.sh
syncToken none -> 1793068228
add 104.192.136.0/21
add 104.192.136.0/24
add 104.192.136.240/28
...
add 131.162.88.0/21
add 131.162.90.0/23
...
prefixes in allow.txt: 96
$ ./atlassian-egress.sh
no change (syncToken 1793068228)
prefixes in allow.txt: 96
To check the "what changed" part I set the saved token back and took the two 131.162 lines out of allow.txt, and the next run printed exactly add 131.162.88.0/21 and add 131.162.90.0/23. What you do with allow.txt depends on your firewall (a security group, an nginx allow list, a ticket to the network team). I'd at least have a person read the add and remove lines before anything gets pushed automatically. Read the remove lines too: since January, 92 prefixes have left the file.
If you don't want to poll, Atlassian publishes changes to an SNS topic, arn:aws:sns:us-east-1:745490931007:atlassian-public-ip-changes. Each message carries the new syncToken, an md5 of the file and its URL, so you can trigger the same script from it.
What I'd do before 1 January
- Search your firewall rules and security groups with
grep -E '104\.192\.1(3[6-9]|4[0-3])\.|185\.166\.14[0-3]\.|2401:1d80:'. That finds Atlassian's 104.192.136.0/21, 185.166.140.0/22 and 2401:1d80::/32, including single addresses from those ranges that someone copied out of a log. A hit is probably a hand-typed Atlassian list, but check its direction. An inbound rule that lets Atlassian call you gets 131.162.90.0/23. An outbound rule to Jira or Confluence gets 131.162.88.0/23. A rule that only covers Bitbucket needs nothing. - Add 131.162.90.0/23 (or the whole /21) to every inbound rule that lets Atlassian call you, which is the five egress rows in the table above. Leave the /16 alone.
- If you restrict where your own people can browse, add 131.162.88.0/23 for the Atlassian apps they use.
- If your endpoints have IPv6 addresses, check that those rules also have Atlassian's IPv6 ranges, because Automation already used IPv6 in our test.
- Move the list to a scheduled job built from ip-ranges.atlassian.com, like the script above, with a person reading the diff.
- Leave the mail filters for Atlassian's notification mail alone (a mail server Jira reads from is covered in step 2). Leave your Guard IP allowlist alone too, unless you added Atlassian's IPs to it so Automation can call your own site. In that case add 131.162.90.0/23 there as well.
- In the first week of January, send a test webhook to a receiver outside your firewall and check the source address.
Have you got a firewall somewhere with a list someone copied years ago? Or a reason you can't sync from the JSON (I know some network teams won't let a script near their rules, and I'd like to hear how you handle it)? Tell me in the comments.
Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.
Top comments (0)