Pushing every customer into the cloud in a questionable way is one thing but to hinder paying clients in doing debug work by fetching log files easily is something different. Instead we have to ask to get log files? Seriously? That feels like being a child required to ask to get out. With the exception that kids don't have to pay.  

What if paying clients need logs frequently to narrow down an issue in prod system? With no possibility to easily replace an existing sandbox?

Is it that hard? 

So you let us wait since 10 years? Congrats, that is quite a good customer experience.

2b59c2db789c

I don't see what would block Atlassian from giving access to the logs. We had logs in Server. We currently have it in Jira Align due to the connector and Enterprise Insights with which we can pull specific logs.

Easy. They don't want you to administrate or understand the tool at all. You should rely on them doing the admin part... so they can charge you more...

Hi Atlassian,

The ticket summary and description don't match. Can this please be corrected. The Description in a narrow scope (webhook failure handling), whilst the summary is very broad (log ingestion). Please either fix the Summary to narrow this down to WebHook Failure, or broaden the scope of the description to include other use cases for customers to automatically ingest logs via our log aggregation tooling

For any watches of this ticket for the Webhook failure use case...

I voted for and watch this ticket because webhook failure handling is something that I want to see improved, however when discussing it with Atlassian support the engineer proposed workaround.

Jira Automations send failed executions to the owner of the automation. Ergo, swap the Jira Webhook config for a Jira Automation config. You'll need to know the JSON that the webhook sends and populate values into it with Smart fields, so it is a bit clumsy.

For mission critical tasks, we have the "owner" of such automations linked to a mailbox ingested into OpsGenie linked to JSM, so that any failures create an Incident ticket in our support project for our team to investigate and resolve.

I don't see what would block Atlassian from giving access to the logs.  We had logs in Server. We currently have it in Jira Align due to the connector and Enterprise Insights with which we can pull specific logs.

 e75809f5270c, I hear you. 
 
I've just had a great meeting with some folks at Atlassian, and this is one of a few issues I have highlighted with them. I'm not expecting grand winds of change, and we will see what their follow through is. I do have commitments from them to take a look and I am hopeful about the results. 
 
So far, it genuinely appears as though they have had some growth and brought in team members to help connect back with the community in positive ways. The folks I've talked to seem absolutely committed to engaging in conversation about resolving some of these issues as opportunity allows. A daunting task, given the backlog. It's not going to happen over-night. And we might not get traction on all the things we think are important, simply because we don't have the full picture. But hopefully they will remain committed to keeping us informed and working to resolve the most important issues with us. 
 
Let's watch patiently, and continue to encourage productivity!

Thanks for the insight William.  Been a Jira user for 15+ years and have always been an advocate, but I think I'm going to look for something a little more out of the box in the future.  Good to hear you have an ear with Atlassian, I have the impression they really don't care what users have to say and I don't usually create suggestions or post on cards as I feel it won't be heard.

e75809f5270c, I believe the problem lies in the fact that Jira cloud can not display more than a certain number of backlog items. With as many issues as Atlassian has ignored in favor of having them taken over by the marketplace so that they can get a cut of that sweet revenue pie, I believe they are no longer able to even see these issues in their sprint planning.

They have been stymied by their own product. And, it's funny... because we joke about things getting lost in the backlog, and we use tools like Jira to PREVENT losing /projects/ to atrophy. And yet... Atlassian can't even manage their own backlog effectively or strategically. At least, as far as I, the consumer, can see. 

But I do continue to advocate for us. I even have a meeting with some of the fine folks over at Atlassian coming up, to discuss a general "why", regarding a lot of these things. This item in particular, along with others. Like, why things keep getting deferred to the marketplace. Is it really revenue driven? I see no other reasons to push features OUT of Atlassian core, only to have them taken over as paid apps. shrug. How many companies will have to jump to another product because add-ons we require are not security compliant? Especially in the case where we previously had security controls in place, and no longer do!

We'll see what they have to say. My long term planning right now, is to slowly find and adapt something else. I don't plan on being caught on the back-foot when the next thing changes, and I'm no longer in compliance. I'm going to have options in place already. 

would be helpful to have a field here with Atlassian's thoughts about whether this is something they are entertaining to fix or have no plans to ever address.  Many many cards I see marked as suggestions are around a decade old.  Seems like ~100 comments since 2015 could have been spared if no intention to fix.

Well. Here we are. 

Atlassian wants to off-load a bulk of their work to third party "partners" via the marketplace.

My security team is now concerned that we can't audit these add-ons. In fact, from this day forward, we are no longer ALLOWED to purchase or install any Atlassian add-on that isn't in the bug-bounty program and has no security conformance data. 

So, Atlassian's play to get more marketplace bucks has just effing FAILED. There will be NO MORE purchases of any add-ons that we can not vet via our own scrutiny of the security logs. Period. 

Atlassian... you dun effed up. Good luck in your future. Today's inability to grow and expand our Jira instance marks the final nail. This is going to create executive frustration, and we're going to be told to find another solution. GREAT JOB FOLKS! YOU DID GREAT TODAY!

+1 Even if Atlassian support team is very reactive, I think we all still need a minimal proximity support to be able to give a quick look in application logs (mainly because all system logs should be specific to cloud architecture)