nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why is Atlassian promoting Shadow IT? Or Accidental IT?

Darryl Lee

Why is Atlassian promoting Shadow IT?

So, in their documentation, Atlassian warns about the dangers of Shadow IT and even talks about how Atlassian can be part of this problem:

"In the context of Atlassian, you’re unable to centrally manage these products from your Atlassian organization. This means that you won’t find them under the Products tab at admin.atlassian.com with the rest of your organization’s products."

So then, surely Atlassian must provide some tools to IT administrators to manage shadow IT? And why yes, yes they do, as described in Discover products your users administer. Oooh, what's this: Manage your users' requests for products? Screenshot 2024-06-19 at 4.12.09 PM.png

Wow, you mean I can choose to prevent MY USERS from creating these problematic "shadow" instances of Atlassian products? That sounds EXACTLY what I need!

Oh, but sad trombone we don't have Enterprise Cloud.

Screenshot 2024-06-19 at 4.14.58 PM.png

How much would Enterprise Cloud cost?

So our smallest instance is a JSM of 300 agents. Enterprise would cost $48,000 more per year. Is this worth the extra hours I spend having to delete instances? Hm....

Oh but wait, reading the screenshot above "update your request settings for each Enterprise product" (emphasis mine). Ok, that'd be $148,000/yr more for Confluence (5000 users) and $236,000/yr more for Jira (6000 users).

Ah well. I guess we should just hire an intern then.

Hrm.... I see this has been discussed before, ad nauseum. Or perhaps just ad nauseating:

Cloud Enterprise admins can now proactively manage product requests
CLOUD-10325 - Allow non-Enterprise administrators to control managed users' associated sites and products
ACCESS-1651 - Premium organisation admins ability to approve or deny the creation of new sites
ACCESS-1272 - Allow to block non-administrators from creating new organizations

And the OG ticket, closed after 1600+ votes after they "fixed" it, but only if you pay for Enterprise:

ACCESS-1468 - Allow Administrators to control managed users' associated sites and products

Some highlights:

"Lets call it what this is, hiding the age of the ticket by creating new ones. Now instead of looking almost 4 years old, it's just a recently created issue."

--mattpatenaude comment - 06/Oct/2023 9:28 AM the day Atlassian "resolved" the issue

Not Shadow IT, but Accidental IT

Here's the thing though. We migrated about to Atlassian Cloud about a month ago - Jira, Confluence, JSM. Users want to use it. (Well, they don't have a choice.)

But users… get confused. In the nearly one month since we migrated, we've had nearly a dozen new instances created by mistake.

How does this keep happening?

Google

Users don't remember that our servers that used to be named jira.COMPANYNAME.com or confluence.COMPANYNAME.com are now COMPANYNAME.atlassian.NET. (.NET? Really? Ahem, CLOUD-6999)

So they Google it. Or type it into their browser bar, which… Googles it.

And they end up here:

Big Blue Buttons

And so, they click on Confluence. Which takes them here, with two very big, friendly, blue buttons, and one very tiny "Sign in" link.

Now, those of us who are Atlassian Admins know that you're not supposed to hit those blue buttons, but instead click on the very tiny "Sign in" link:

Sign up/Login? What's the difference?

But I'm guessing that 11 people at my company did not. Instead they clicked one of the blue buttons, and oh look, it's what kind of looks like a login page. Oh and we just migrated to Confluence Cloud, so perhaps this will give them some kind of tutorial. It does say "Get started with Confluence":

Now because me and my team have done the work to connect Atlassian Access Guard to our IdP, Confluence happily recognizes that user's account. They may have even been redirected to our Azure AD page and done their whole SAML login. Very secure! And now they're back.

Go team go!

Huh. "roku-team-...." that sounds right. I work for Roku. I'm on a Team. Let's go hit another friendly blue button.

And that… is why I now have an Excel sheet tracking "shadow" Atlassian Cloud sites created by mistake, including emails addresses of the users who mistakenly created them (who have ALL indicated they did this on accident), when I cancelled the sites, and assuming the cancellation actually goes through (which it often DOES NOT), when I have deleted the Organizations that were also set up for each site.

I guess this is a huge win to Atlassian's Sales Team who have designed a very efficient "funnel" to get users to sign up for new Atlassian Cloud sites. (Assuming they only measure sign-ups, and not cancellations by irate Atlassian administrators.)

Accepted answers

Darryl Lee

OMG. I think they finally fixed it. Thanks to @Charles Blaxland over in CLOUD-12193 for the heads-up.

Could this be the end of our #accidentalIT nightmare? We can only hope!!

All comments

Kristian Klima_gtcuat

Shadow or accidental, when it comes to consequences, it doesn't really matter.

This was posted on a Community forum yesterday.

https://community.atlassian.com/t5/Confluence-questions/advice-after-anonymous-access-allowed-rampant-page-and-draft/qaq-p/2731249#M316076

Ed Letifov _TechTime - New Zealand_

And the cynical analysis of the problem behind the scenes is no doubt:

"a problem exists between the keyboard and the chair"

I feel you @Darryl Lee especially on the "assuming the cancellation actually goes through" bit.

And then someone will design a technological 3rd party solution faster than proper controls are implemented. And charge money for that too. Maybe this is my💡moment?

Darryl Lee

Oh man, that is awful. I really hope he has backups from Aurora.

Darryl Lee

So not an answer, but even worse news:

Another Community Leader tells me that even with Enterprise, he's still seeing rogue sites show up, and he suspects it's because Atlassian's "Product Requests" feature doesn't cover/block requests from folks on their mobile devices.

That is... not great, considering that for many users (ahem, YOUNGSTERS), they spend more time on their phones than in front of computers.

As previously mentioned, we're not on Enterprise, but I just checked, and the path to accidentally creating a site via mobile is MUCH MUCH easier. Oof:

So then, play in 1 act:

Customers: Hey, can you stop letting our managed users create new sites?
Atlassian: Sure, give us that Enterpri$e Money$
Customers: Grrr, ok here.
Atlassian: Haha, did you think it would also prevent mobile users from creating new sites? $ucker! For that feature you'll need to pony up for Enterpri$e Plu$!

Darryl Lee

Welp. This is a pretty depressing answer, found in a recent comment on CLOUD-10325:

I have over 2 years of emails and meetings going back and forth with Atlassian on this issue. I even worked with their Shadow IT team while they were building the solution to block these from being created...

However, to date, it's only a feature for customers on their Enterprise plans.

I have confirmation provided to me today, Friday June 21st 2024, that Atlassian has no plans to extend the feature to non - Enterprise customers.

Here is their email:

I truly appreciate your patience as we delved deeper into this matter internally. I reached out to [*Name removed because I care about privacy and data security; unlike Atlassian*], the Shadow IT product manager you previously engaged with, and he has confirmed that, unfortunately, we will not be including the shadow IT controls that enable you to block product creation, specifically "Product Requests," in any edition other than enterprise at this time. It's important to recognize that this challenge is not unique to our tool but rather a common occurrence in the software industry, reflecting the growth mindset that all SaaS providers strive to foster.

Hum. That sucks.

Darryl Lee

Ooh ooh ooh. I know. Atlassian is leaving this as an opportunity for a third-party vendor to "fill the gap" (classic Atlassian)!

I mean, the Organizations REST API does have endpoints to Get organizations (so you can find out when somebody has created yet ANOTHER company-team-zx82asd site, by I guess checking every day ...)

And it even has a new (Beta!) endpoint for getting workspaces:

A workspace refers to a specific instance of an Atlassian product that is accessed through a unique URL. Whenever a user initiates or adds a new product instance, it results in the creation of a distinct workspace.

This API will:

Return a paginated list of workspaces in a given org

Return more details about an organization's products (including product URL).

Great! So now all we need is an API to:

Request cancellation of sites that were created accidentally
Delete organizations that were created accidentally

Oh, and your app is going to need to wait 14 days for cancellation to occur. *Sigh*. Oh and sometimes even then you can't delete the organization.

Maybe your app can also file a support ticket to ask them to fix that?

What a great opportunity! What marketplace vendor is going to step up to create this awesome tool?

Darryl Lee

OMG, I missed @Rob Allan's comment from yesterday:

"If you have the improved billing experience, you have to wait an additional 60 days after the products are deactivated to delete the organization."

Seriously Atlassian? Is this a joke!??

From: https://support.atlassian.com/organization-administration/docs/remove-domains-and-products-from-your-organization/

So yeah, ok, your app will have to wait 60 days.

Darryl Lee

So, last answer for tonight (or maybe ever, in case the person unhappy with my comment on CLOUD-10325 also decides to delete this question):

OF COURSE Atlassian wants to make it easy to sign-up for their products. It's how they got started.

Atlassian - 20 years of Atlassian, 20 lessons learned

Software should be bought, not sold.
With most of our target market across the Pacific ocean in the U.S., Atlassian could either invest heavily in a traditional sales team or invest in building a self-service purchase experience. Mike and Scott chose the latter, even though it was a bit risky. They woke one morning in 2003 to find an order from American Airlines lying on the fax machine. According to company lore, they looked at each other and said, “Did you talk to them?” “No, did you?” … “Holy shit! American Airlines saw Jira on our website and bought it just like that!”
Forbes - Product-Led Growth: The Atlassian Way To $2.8B And Counting
They began by looking online for tools they needed to complete their work. They realized that it was nearly impossible to get access to the software. You could go to IBM’s website but couldn't download software.

SaaS had yet to develop. Walls existed between the users and solutions. So, they were forced to say, “Let's just get our tools online and make sure people have access to them.”

They posted online and realized they had to have a significant market if they were going to sell products online. They said, “Hey, we have to think globally from Day One.” They started doing some Google search engine stuff early in 2002 to get that distribution.

They believed they should make the software so inexpensive and easy to use that people would download it, try it and buy it.

Within six to 12 months, they got a check in the mail for $10,000 from a major US airline. So, they doubled down.

And it would be fair to say that this was part of the plan for a while though. I mean, back in Dec 2020 Jay Simons laid it all out in this podcast:

To borrow from the analysis at How They Grow - How Atlassian Grows:

Eventually, most companies end up with a blend of these strategies. Like Atlassian today, who has a tiered pricing structure with trials (free, standard, premium, and enterprise). But, on their path to their first 1K customers where they were on a quest to get into as many companies as possible, not just the companies with the most seats — they kept it much simpler.

> [In the early days], we were so focused on reducing the cognitive load on the customer that was coming to us. And if you have four different versions at four different price points, that’s very difficult to help the customer wade through.

> It helped us when we were unknown and young and small because it was just so simple — the KISS principle actually worked in our favor, where you just came to the web and it was like, ‘Oh, Jira’s one price’. I just need to think about the number of users, I don’t need to think about, ‘Does it include this? Does it get SSO and the security stuff or no, that’s in the enterprise package. Is it worth twice as much for that stuff?

> There are all these questions that the customer gets bogged down into thinking about and that’s friction. [Which] can be okay in the right context with the right approach, but in our particular case, we chose not to introduce it. We were just going to make it simple. We're going to go for high velocity volume customer acquisition, and we're going to reserve future opportunity to have those expansion conversations with those customers.

— Jay Simmons, via First Round

Pressing on that last comment of Jay’s there a bit more. To to do that effectively, they used a free trial to bring users in, and then focused on getting them hooked so they’d then set off a domino approach and get others join. And with a low price point, people could easily try and buy Atlassian with a credit card rather than going through the headaches of financing.

As mentioned, they eventually expanded their pricing structure. But by then, as Jay says, “They’re already hooked. They’re already deeply committed. They love the product, and it’s used by thousands of users. Now they just want some extra security features and if we want to charge them for it, it’s probably easier.”

(Boldfacing mine, because welp, it's right there.)

Dave LIAO

@Darryl Lee - thanks for putting this together.

I'm also affected by this system behavior, and it's frustrating.

In terms of luck, so far no one has spawned a Cloud instance out of malice (i.e. trying to work around my team), and it has all been accidental.

I voted up the JAC requests that directly affect my team/company, and also will mention this to my Atlassian rep to know this is a concern for us.

Darryl Lee

To be clear, my example above is if you have previously logged in on your phone to your company's Atlassian site (which I assume my users must've done once before), but shows up even if you have logged out.

If you not ever logged in (or clear all Atlassian cookies from your browser, which, can you even do that on a phone?), you will see this screen:

(Screenshot from an Incognito session)

From there typing your email (if your company has claimed your domain) and clicking "Sign up" will take you to your company's SSO. OR, since we are on Azure, some users will click [Microsoft].

In any case, once authenticated, users will end up on the "Welcome back" page. Actually trying from Incognito just now, I'm seeing this page is even more streamlined:

It's kind of a bummer that if they're Welcoming me back, they're not showing me https://start.atlassian.com/ (which I guess now is https://team.atlassian.com/)

Darryl Lee

So over in https://jira.atlassian.com/browse/CLOUD-10325 (where I might be banned?) @brian.g wrote:

I just recieved a potential ray of hope.

It was suggested that we could create a firewall rule in our corporate network/VPN to restrict network access to the following addresses:

https://admin.atlassian.com/o/create

https://www.atlassian.com/try

https://www.atlassian.com/try/*

so users could not create Atlassian organizations themselves and could not open the pages that allow them to start their own site subscriptions.

Please note that such network rule will not block you from adding additional products/sites to your current organization, but will be a blocker should you legitimately require to create another cloud site for your company in a separate Atlassian organization.

Hrm. I guess I could ask our network team if they can redirect those URLs to a proper login page. Or to a Confluence page asking if the users were trying to create a new site.

Thanks!

Peter Fjelsten

Thank you for your quest.

I agree wholeheartedly with everything you have written.

Atlassian need to fix this or it will be just another reason for admins to looking for alternative products - IMO Jira is overpriced. Yes, they do not have all the features but are a fraction of the price. We're a 1000 user installation.

Michiel Schuijer_jlry2w

And the saddest thing here is, I can only "like" this comment and your very astute post

Darryl Lee

Ugh. I realize that using the official Get organizations endpoint won't work because for discovered products, you are NOT the org admin until you add yourself.

SO ok, I guess I've gotta go rogue.

If you export your admin.atlassian.com cookies from your browser, this curl command will dump all of the rogue sites to a JSON file:

curl -b cookies.txt \
https://admin.atlassian.com/gateway/api/admin/v1/orgs/{org-id}/products/unmanaged> 20240924-discovered.json

So now I have a list of sites that includes when they were created, who created them (so you can send them a nice email), and their status. You ALSO have the org and site IDs, which is important for the next step:

You'll need to make yourself an org admin so you can request the site be cancelled.

curl -b cookies.txt \
https://admin.atlassian.com/gateway/api/adminhub/organization/{org-id}/shadow-org/{rogue-org-id}/join-as-org-admin?siteId={rogue-site-id} \
-d {"aaId":"YOURUSERID"}

But these are just some building blocks. And they rely on a cookies instead of a proper Org API key.

If I really want to automate this, I'd need to:

Send an email to the creator, to confirm that the site was created by mistake. (Fun fact, since our onboarding of users to Cloud back in March 2024, out of 36 sites created by non-admins, exactly 0 of the creators got back to me to say they did it on purpose.)
Request Cancellation/Deletion of the site, with explanation Other: "Created by mistake due to atlassian.com not offering path to log into existing site"
File a support ticket that request deletion be expedited, because I don't want this site hanging around for 2 weeks.
Automatically reply to the support ticket confirming my request, because they want to make SURE you want to delete the sites you requested be deleted.
Monitor the support ticket to see when they will finally delete the site.
On the day the site is supposed to be deleted, check if it has, and then attempt to delete the Org.

Because yeah, those are all manual steps right now.

Darryl Lee

So this is fun:

Last week I found that Product Discovery, er I mean Discovered products failed to discover a site that was created 2 weeks prior. No email, but worse still, it didn't even show up on the "Discovered products" page, which is what all of us poor standard users get. (HUH. Maybe they could add it to Atlassian Guard Premium, for less than Enterprise, but more than Standard.)

BUT WAIT. I also found a site created THREE (3) MONTHS ago that it did not find or list or email me about.

I mean, it had one job: Discover products.

(Yes, I've opened a Support Ticket. The Dev team is looking into it.)

Michiel Schuijer_jlry2w

With a trial of Atlassian Guard I was able to find out the current state of shadow IT on our organisation: 16 sites created accidentally in the past months only (between July and October).

The standard answer when asking my colleagues why they created a site was "oh, sorry, I didn't know I did that".

It is also easy to spot these types of sites from the naming convention and the fact there are usually only about 5 - 15 people added, the number of their team members...

Site name examples: ourcompany-team-xwl3ovsb.atlassian.net

Removing them is a burden and it is even worse for the older ones where the employees have been deactivated because they left our company and it is necessary to create support requests to "Billing", to ask if I can be added as org admin so I can then ask support to remove them?!

Oh, and when our Guard trial is over this is probably not possible anymore, because we're not getting the budget for Guard. Does mean I can't do the burdensome work, so maybe that is a relief?

¯\_(ツ)_/¯

Darryl Lee

Ohey! I was told at Team 24 Europe last week that Atlassian has supposedly FIXED the bug that still allowed managed users in orgs with Atlassian Guard Enterprise to create sites on mobile devices (even if Product Requests are set to require review).

So hey, paying for Enterprise is totally worth it now. ;-P

Darryl Lee

via GIPHY

Ugh yeah, it's infuriating that without Guard, you can't do anything about these sites.

And these emails that notify you about them without actually TELLING who created it or what the site URL is are infuriating.

It's does feel a bit like a hostage/blackmail situation:

                        TAKEN (ADVANTAGE OF)
                        based on true events

FADE IN:

OFFICE BREAK ROOM
People are enjoying coffee and bagels, chatting about how great RTO is. 
So much synergy is happening.


CLOSE-UP COMPUTER SCREEN

Ominous music starts playing. Ding of a new mail. (Picture below)

              From: "Atlassian <noreply-ofcourse>".
              Subject: 1 product created outside YOUR COMPANY.

            VOICEOVER (Liam Neeson-like actor):

     So... someone in your domain, which you've gone to the 
     trouble of verifying, so we know you care about such things... 
     they've created a site that where they can:

Invite other users in your company to access

Invite people outside of your company to access

Make the pages/spaces/projects/issues visible to the world, without any login

Share PII, PHI, HIPAA, proprietary, top secret data without ANY REVIEW, again, using accounts with YOURCOMPANY domain."

     If you ever want to see these sites, or know who created them, 
     you need to pay us $4/user. We accept credit cards and of course 
     can issue a quote for your billing department to issue a purchase order.

     Remember: Until you pay us the ransom, any of your users can 
     create a huge security headache for you!

     We'll be waiting.

Screenshot 2024-11-01 at 3.51.04 PM.png (Sorry this screenshot is from an email back in 2021 when we didn't subscribe to "Access".)

Darryl Lee

Hum. Worth a separate article, methinks:

What's another word for blackmail?

Michiel Schuijer_jlry2w

I tried this approach with the cookies today, because we're seeing an uptick in sites created outside our domain, and I wanted a such a useful list, but unfortunately our Guard trial has ended and without that it is not possible do this.

You can test it by visiting the URL in question

https://admin.atlassian.com/gateway/api/admin/v1/orgs/{org-id}/products/unmanaged

if it returns "Subscription required", you know you need Guard

Hans Polder_7ci2ta

I wholeheartedly support your frustration @Darryl Lee , it has been an evolving issue in the companies that I have worked for. And even with the new 'Add admin' feature, it is still annoying and time consuming to wait the unpredictable waiting period after cancelling the products, to be able to hopefully delete the organization that was created with it.

On the other hand, it's one of the things that keeps us busy and employed, so.... 😅

Darryl Lee

Hi @Hans Polder - If you file a support ticket (which I do, and which I've very nearly automated), you can request that they expedite the deletion process, and they will also give you a definitive date when the site is scheduled to be deleted.

Yes, I track all this in an Excel sheet so I remember to delete the org when the site is finally deleted.

Truly, I would rather be doing other things with my time, and my employer would too.

Sid Pathirana

Hi @Darryl Lee - we occasionally have this problem as well, although not frequently as you do!

From previous experiences, I know the standard cancellation and deletion process can take months as it factors in:
• Subscription cancellation date
• Next billing date
• Suspended for 15 days of grace period after the billing date
• Retention period of 60 days after the grace period before the deactivation of the product and removal from the site
• Deletion of the Org

You mentioned about having nearly automated the process to submit a support ticket for the deletion process - I'm interested in that, are you able to share more details please?

Darryl Lee

Well, this is progress:

@Charles Blaxland has gotten @Derrick Nguyen to file this Suggestion:

CLOUD-12193 - Reduce occurrences of accidental site creations

I think all the major points are covered, so I look forward to everyone voting it up.

I don't look forward to Atlassian letting it languish for several years. :-/

Michiel Schuijer_jlry2w

Great. I upvoted the suggestion as soon as I saw your post, but honestly, it is too little, too late to me.

As of today, I got the email from Atlassian showing me

That is 4 products on Thursday and again 4 on Friday, now totalling 61!!

Even with Guard, this would be challenging to 'fix'.

I don't understand why Atlassian would want this to happen?! It is not going to increase their profits or anything, and I dare to say it does the opposite.

That's just me of course...

Darryl Lee

OMG. I think they finally fixed it. Thanks to @Charles Blaxland over in CLOUD-12193 for the heads-up.

Could this be the end of our #accidentalIT nightmare? We can only hope!!

Dave LIAO

Welcome back indeed! 🙌

This has been such a fun adventure... to the eventual end of #AccidentalIT!

Hans Polder_7ci2ta

Thanks for your continued raging @Darryl Lee !

Despite the new setup, still, a new rogue site was created yesterday - I guess someone was really eager to create a new site... If it happens again I might check with the user to see how they created it in the first place. Maybe there is still some approach that needs to be improved.

Nowadays, I'm simply joining as admin and removing the site creator without notice. I used to contact them directly, but they all sing the same song: I had no clue - I'm not using it - You can remove it

Darryl Lee

Oh man! I ALSO got a new site created accidentally yesterday!

It had the random "roku-team-XXXXXX" sitename, which is a sure sign that it was part of the broken site creation workflow.

My guess is that that they were trying to log into Confluence from their phone, as it seems that the mobile pages for Confluence and Jira do not have the new UI that displays and links to existing sites the user has access to.

Darryl Lee

Oh hey, happy June, everyone. Atlassian has made this problem worse. MUCH WORSE.

What in the WHAT Atlassian? Making Shadow (Accidental) IT even easier!

Vilius Šumskas

It's even worse than that, when you realize that every new site is automatically onboarded to Rovo app now, which cannot be deleted by org admins https://jira.atlassian.com/browse/ROVO-144 . You have to contact support to delete every new organization now.

Vilius Šumskas

For anyone having enterprise with managed Microsoft Edge Configuration, you can do this with Configuration Policies. Create one policy, let's call it "Block Atlassian trials", and add those URLs to URLBlockList. Assign that policy to all users. Now create another policy named "Allow Atlassian trials", and add those URLs to URLAllowList. Assign allow policy to real Atlassian Org Administrators.

Similar option exist in managed Chrome too.

Now the only issue is with unmanaged PCs and mobile devices. Also with other unmanaged browsers.

Having these rules at network/VPN level requires HTTPS inspection which is not possible in a lot of cases.

Doug Rutherford

Even support can't delete Rovo as of Aug 2025. Their most recent answer to me was that I have to wait the full 3 months after deactivating the automatically added Rovo for it to time out before I can delete the org. They added that they cannot accelerate the Rovo deletion at all.

Darryl Lee

I clicked Like, but I do not like this. But also, I HOPE support is just confused, and that there are not different timelines depending on your tier, because Support WAS able to help us expedite an Org deletion.

We are on Premium, and here's the timeline of a recent accidental site/org creation and deletion:

6/18 we canceled Jira site, filed ticket asking to expedite deletion
7/4 they said Site was deleted
7/7 we said we still coudn't delete Org
7/7 they replied:
After further investigation, I can see a Rovo parent subscription that seems to be active and linked to this Cloud site https://ACCIDENTALSITE-team-f1uuzkl4.atlassian.net. I have contacted our internal team to confirm if this might be preventing you from deleting the organization and what our next steps should be here.
7/11 we said we still couldn't delete Org
7/11 they wrote:
Our internal team informed us that the Rovo parent subscription is now scheduled for deletion on July 22. I'll freeze this ticket until then. Once this subscription is deleted, you should be able to delete the org.
7/22 we were able to delete Org

Let's hope the recent layoffs in the Customer Support Org don't make this process any murkier. :-/

Darryl Lee

HI Sid - I toyed with the idea of writing a script to automatically submit a ticket based on a template that let me plug in the Site that was accidentally created.

I got as far as sniffing the POST calls that the Support site made upon ticket creation, and then hacking together a shell script that replayed the call using curl, letting me substitute in the new site.

When (UGH) I get another accidental site, I'll give it a spin to see if it still works, and if so, I'll post it here, although fair warning, it's ugly.

Abbey Lawe

Hello all,

I'm a Product Manager on the Admin Experiences team, conducting research on this issue.

Your feedback has already helped us ship several updates to www.atlassian.com with the purpose of reducing site proliferation. We’ve heard from several customers about a recent resurgence and are eager to better understand how we can continue to address this.

If you’re open to sharing more about your experience as an admin, please book time with our team here [https://atlassian.zoom.us/zbook/abbey-lawe] to help inform our roadmap. We'd be grateful for your insights.

Thank you for your time and continued feedback!

Abbey Lawe

Atlassian, Product Manager

Darryl Lee

So, is it necroposting if it's your own post you're resurrecting from the dead? :-D

Well, I would posit that the problem isn't dead because people are still actively commenting on CLOUD-12193 - Reduce occurrences of accidental site creations.

Since the new year, there have been 17 comments about this issue, which leads me to believe #accidentalIT is alive and well.

I am curious about what kind of volume of accidental site creations those commenters are seeing, because it was really bad for us back in 2024->2025. (We migrated in May 2024, which led to a lot of users having to "re-learn" how to log into Jira/Confluence.)

I've been tracking our accidental site creations in an Excel sheet, and Copilot helped me make a graph:

For context, we had a 6000-user license for Jira back then, 5000 for Confluence. There were twice as many Confluence sites created than Jira. (~50 vs ~20)

I'm very interested to learn:

How many accidental sites are created per month?
How many users do you have in Jira or Confluence?
Are the accidental sites Jira, Confluence or Service Collection? (We've mainly been seeing accidental Service Collections mainly what we've been seeing since Oct 2025.)