I’ve shared a couple of early Cascade demos here before. Since then, I finished this one-minute walkthrough of the current version.

Now I’m deliberately pausing feature work because I may be trying to solve too many Jira annoyances at once.

https://reddit.com/link/1w4fb4q/video/lgxfttf8gxmh1/player

I originally built Cascade for three problems I kept running into:

• Jira notifications told me something changed, but not the exact before and after.
• Hierarchies were difficult to scan, and exporting them produced a flat list.
• Reading and updating issues meant constantly opening more tabs.

The current version combines an Inbox with exact diffs, a tree with slide-out issue details, search and filters, Assigned to me, bulk actions, hierarchy-preserving exports, and keyboard navigation.

For transparency: I’m the developer. Cascade is an independent Chrome extension, not an Atlassian product or Marketplace app. It works through your existing Jira session and permissions and doesn’t require a separate Cascade account.

If you use Jira heavily, which of these is useful enough that you would actually keep an extension installed for it?

1. Knowing exactly what changed
2. Navigating the hierarchy without opening tabs
3. Bulk work and hierarchy-preserving exports

And which feature looks useful in a demo but probably wouldn’t survive your real workflow?

Blunt answers are genuinely more useful to me than “looks good.”

Hi everyone,

I’m curious how other teams handle unresolved inline comments in Confluence.

Inline comments work well when reviewing a single page, but when comments are spread across many pages, it becomes difficult to know what is still unresolved without opening every page separately. I’m wondering whether other teams have the same problem or if you already have a good process for managing it.

To be transparent, we recently built CommentLens to help with this. It shows the number of unresolved comments on each page and provides a macro and search action for finding comments across pages or spaces.

I’m mainly interested in understanding whether this is a real problem for other teams as well. If your team regularly uses inline comments and faces the same issue, I’d be happy to provide a free license so you can test the app in your actual workflow and share your honest experience and ideas for improvement.

Feel free to comment or message me if this sounds familiar.

I've been thinking about this while working on an upcoming webinar we're hosting with the Atlassian team around AI governance.

When should an AI tool actually move from "employees are experimenting with this" to "we officially support this"?

Is there a specific threshold you look for?

Number of users? Type of data involved? Business value? Security review? Something else?

I'd be interested to know what criteria you use before turning an AI experiment into an approved business tool.

Maybe there are some perspectives or challenges we haven't considered yet that we can also cover during the webinar.

Hi, I'm building a Forge app I plan to eventually monetize via "Paid via Atlassian," and I want to understand the actual verification requirements before I get to launch.

I'm currently operating as an individual/solo developer, not a registered company — planning to register a business entity later, once the app is generating meaningful revenue.

From what I've read so far, there's some conflicting information:

* The Marketplace docs mention a Partner profile can be an individual ("like Adaptavist or John Smith"), and payouts go to a personal bank account via EFT. * Other guidance mentions "business verification" requiring proof of business existence (a business license or tax ID) before a paid app can be listed. * The paid-app submission process itself asks for bank details and a tax ID as part of setup.

My specific questions:

1. Can an individual developer (sole proprietor, no registered company/LLC/Pvt Ltd) publish and sell a **paid** app on the Marketplace, or is a registered business entity a hard requirement?
2. If an individual can publish, what specific documentation is required at listing time (e.g., a personal tax ID/PAN in India, vs. an actual business registration certificate)?
3. Is there a revenue threshold below which individual verification is sufficient, and above which formal business registration becomes required?

I'd like to get this right before I invest more time building, rather than discovering a blocker right at launch. Thanks in advance for any clarity — happy to be pointed to the definitive docs if I've missed them.

Hi, I'm building a Forge app I plan to eventually monetize via "Paid via Atlassian," and I want to understand the actual verification requirements before I get to launch.

I'm currently operating as an individual/solo developer, not a registered company — planning to register a business entity later, once the app is generating meaningful revenue.

From what I've read so far, there's some conflicting information:

• The Marketplace docs mention a Partner profile can be an individual ("like Adaptavist or John Smith"), and payouts go to a personal bank account via EFT.
• Other guidance mentions "business verification" requiring proof of business existence (a business license or tax ID) before a paid app can be listed.
• The paid-app submission process itself asks for bank details and a tax ID as part of setup.

My specific questions:

1. Can an individual developer (sole proprietor, no registered company/LLC/Pvt Ltd) publish and sell a paid app on the Marketplace, or is a registered business entity a hard requirement?
2. If an individual can publish, what specific documentation is required at listing time (e.g., a personal tax ID/PAN in India, vs. an actual business registration certificate)?
3. Is there a revenue threshold below which individual verification is sufficient, and above which formal business registration becomes required?

I'd like to get this right before I invest more time building, rather than discovering a blocker right at launch. Thanks in advance for any clarity — happy to be pointed to the definitive docs if I've missed them.

A lot of adoption reporting focuses on things like logins, active users, issue updates, and page views.

Those metrics are useful, especially when you're trying to optimize licenses.

But I’m not sure they answer a more interesting question:

Are people actually collaborating?

Someone can log into Jira every day without helping a teammate.

Someone can read dozens of Confluence pages without contributing anything back.

Meanwhile, comments, reviews, knowledge sharing, mentions, and cross-team interactions may tell us much more about how people actually work together.

We've been experimenting with measuring those kinds of behaviors across Jira and Confluence and making them visible through gamification.

That experiment eventually became a Marketplace app called Collaboration Champion, but I'm actually more interested in the underlying problem than promoting the app:

What signals would you use to measure real collaboration in Jira and Confluence?

Comments? Knowledge creation? Helping resolve work items? Cross-team participation? Something else?

Curious how other Atlassian admins think about this.

Hey everyone,

We’re looking at enabling the Atlassian Rovo MCP Server so our AI tools (Cursor, Claude, ChatGPT,.) can pull context from Jira/Confluence (via MCP)

Can anyone who’s actually using this in production share:
1. Are you currently being charged anything beyond your normal Jira/Confluence seats for Rovo MCP usage?

1. Have any Teamwork Graph-related MCP tools started consuming credits yet?

2. Any unexpected costs, rate-limit issues, or overage surprises?

3. Roughly how heavy is your usage (calls per day/hour) and what plan are you on?

Would really appreciate real-world experience the official docs are a bit vague on the long-term pricing model.
Thanks

We’re juggling multiple clients with different support tiers and time zones in one JSM queue, and keeping track of who gets what SLA is getting messy.

How are you guys setting this up in Jira so techs aren't just guessing? Native hacks or apps?

GET /rest/api/user/viewissue/search

states that its limited "up to the 1000th user", given the startAt and maxResult parameters of 0 and 50. I would assume that given a projectKey only 1000 users are the maximum of possible result.

But when I paginate I can get up to the 1164 unique users. How is that possible?

I am trying to get a User <-> Project relationship going for our database.

Has anyone using Rovo found it meaningfully better than Claude Code paired with Jira and Confluence plugins (or MCP integrations)?

I’ve been trying to identify the concrete value proposition and am struggling so far. It currently feels like a relatively wrapper that allows Atlassian to position itself in the AI space, but it’s not clear what it delivers beyond what you can already achieve with Claude Code + MCP connections to Jira and Confluence especially when you factor in the additional customization available through skills.

I’d genuinely appreciate hearing what I’m missing. What specific advantages or unique capabilities have you found with Rovo that aren’t easily replicated with the Claude Code approach with a connection to Jira/Confluence etc

Looks like they're having yet another meltdown. Jira tenants unavailable, Confluence unreachable. Support chat is unavailable as well! No update on their status page as of yet.

EDIT: Active incidents now declared

EDIT 2: Looks like service is resuming now

status.atlassian.com

Asking because I’m currently interviewing for a senior technical role based out of the US. Currently I’m employed by another fairly big SAAS company that was bought out by PE several years ago and the culture at my company has significantly declined since January this year (seemingly a trend in most tech companies lately)

The TC at Atlassian is overall much better but I’m seeing mixed reviews as of lately. I’m mostly worried about wlb as while being at a PE company does tend to have lots of layoffs my team is fairly relaxed and seemingly safe from layoffs (for now, but due to some reorgs might change soon).

Apologies if this isn’t the right channel. /r/cscareerquestions tends to skew a bit junior and I didn’t hear anything back from /r/cscareers when I posted the other day.

Hey everyone,

This is a continuation of my initial Atlassian P40 interview experience, which covered the first six rounds.

Role: Software Engineer II, P40
Experience: Approximately five years
Final status: Offer received

Why Was There an Additional Round?

Recruiter callback: August 7, 2026

The original opportunity was primarily described as a backend role. However, the final position included a mix of backend engineering and site-reliability responsibilities.

Because of that, the recruiter scheduled an additional SRE Craft interview.

Round 7: SRE Craft

Date: August 12, 2026
Duration: Approximately 55 minutes
Interviewer: Senior Architect

The interviewer presented an existing system architecture and divided the discussion into three sections. Each section took approximately 15 minutes, with the remaining time used for introductions and questions.

Part 1: Monitoring and Golden Signals

The first section focused on deciding what should be monitored and why.

The discussion covered the four golden signals:

• Latency
• Traffic
• Errors
• Saturation

I explained which metrics I would collect at the infrastructure, service, and business levels. We also discussed alert thresholds, dashboards, and the difference between symptoms and underlying causes.

Part 2: Incident Troubleshooting

The second section involved an incident scenario affecting the system.

I structured the troubleshooting process around:

1. Confirming the incident and determining its impact.
2. Checking recent deployments and configuration changes.
3. Reviewing metrics, logs, and distributed traces.
4. Isolating the affected service or dependency.
5. Mitigating the issue through rollback, failover, or traffic reduction.
6. Communicating status to the relevant stakeholders.
7. Investigating the root cause after restoring service.
8. Creating preventive action items.

The interviewer asked several follow-up questions about how I would prioritize mitigation when the exact root cause was still unknown.

Part 3: Designing for 99.99% Availability

The final section focused on improving the architecture to support a 99.99% availability target.

We discussed:

• Defining SLIs, SLOs, and error budgets
• Removing single points of failure
• Multi-zone redundancy
• Health checks and automatic failover
• Capacity planning
• Graceful degradation
• Retry and timeout policies
• Circuit breakers
• Disaster recovery
• Alerting and operational readiness

The interviewer was interested in trade-offs rather than simply adding redundancy everywhere. I had to explain which components justified higher availability and what additional complexity or cost each decision introduced.

Result

Positive feedback: August 19, 2026
Offer received: August 21, 2026

One week after the interview, the recruiter confirmed that the feedback was positive and that they could proceed with the offer.

The compensation was broadly aligned with publicly available Atlassian P40 figures on LeetCode Discuss and Levels.fyi. It was not unusually high, and the final package also depended on previous compensation and negotiation.

Final Takeaways

For an SRE Craft interview, I recommend preparing:

• Golden signals and observability
• Metrics, logs, and distributed tracing
• Incident triage and mitigation
• SLIs, SLOs, SLAs, and error budgets
• High-availability architecture
• Failure scenarios and graceful degradation
• Capacity planning and disaster recovery
• Reliability versus cost trade-offs

The round was less about memorizing SRE terminology and more about applying reliability principles to a concrete architecture.

That concludes my Atlassian P40 interview journey. I hope both parts help anyone preparing for a similar role.

We've created a custom field in JPD, and want it to be required on create of new Ideas.

Editing the fields, editing the type, editing the create idea... Can't seem to find where I can make our custom field appear and be required on the create dialog.

If anyone has a solution, much appreciated!!

I tried so many times but i can't delete my account. i inactivate all my subscriptions, but it was block because i cant deactivate Goals, Projects, and Teams subscriptions, which are the free apps. it always say that i need to deactivate my something in my billing despite not adding my billing address. i already gave a ticket but i'm still worried since it have my name. Can anyone have an advice for this?

Anyone who's worked in Jira Server knows this pain: linking an issue to its User Story means opening the Link dialog, searching, picking the link type, confirming - way too many clicks for something you do dozens of times a day. In practice that friction is exactly why nobody bothers keeping the structure clean and issues just pile up under epics instead.

So I built Story Link for Jira (Server/Data Center 8.20+). It adds a small button to the issue card - on the issue page, the Kanban board, and the backlog list - that opens an instant picker instead of the native dialog. Candidates are pulled in order: the issue's epic → the active sprint → the project's open stories → a project-wide fallback if none of those hit. Pick one, done, with Undo if you misclick.

It's free, no paid tier planned.

WebStore: https://chromewebstore.google.com/detail/story-link-for-jira/hpjgangmanaifnkcdhlfnhpoioakgebb
Github: https://github.com/deadmoose-ap/jira-storylink-server

Curious if others here have found different workarounds for this, or if it's just something everyone silently tolerates. =)

I’m currently interviewing for a role in the CS org at Atlassian in Germany and would be curious to hear what the EMEA side of things looks like right now? I’ve been seeing a ton of negative stuff here and on Glassdoor and would love to know if it’s any better in EMEA - specifically Germany? Do they make a big deal out of the probation period or is it easy to pass? What’s the performance review process look like and how common are PIPs? I work at a similar sized tech company right now, so very much used to surprises and sudden changes but have been here for a while so it’s comfy and I’m tossing up whether the effort of continuing the process is worth it..

Hey team ... my 2FA device got wiped as I was doing something with it. On that same device I had my backup codes (yeah dumb on my part).

So I read the online docs and it talks about the process to reset my Atlassian account. The options it shows do not exist (recovery codes, don't have codes). I can reset my password but there is no place to reset 2FA.

To reach support, I have to login to their portal .. obviously I cannot.

We have premium support but I don't have the phone number anywhere, and guess what? Their docs say that the phone number is in the portal once I login ... go figure.

Does anyone know how to reset 2FA in this situation? I am the account and billing admin ..

Thanks!

Hey all — beyond atomic tasks like creating or reading individual issues, what are some \*\*end-to-end operations\*\* you perform (or would like to perform) as part of your SDLC workflow using Jira and related tools?
For example, are there workflows where you need to coordinate multiple Jira actions, projects, or tools to achieve a broader outcome? I’d love to hear about the real-world flows you find valuable or wish were better supported.

GitHub users get gh. Bitbucket Cloud users get… nothing. No official CLI, no good third-party one. So I built bb.

One binary, no runtime, unsafe forbidden. Reviews PRs, reads/writes comments, checks build status — all without opening a browser tab.

$ bb pr list --build ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ ID TITLE STATE BUILD SOURCE → TARGET AUTHOR REVIEWERS │ ╞══════════════════════════════════════════════════════════════════════════════════════════════════════════╡ │ 42 Cache session lookups Open SUCCESSFUL feat/cache → main dev Dana ✓ │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Also does bb pr mine — every PR you're author/reviewer on, across every repo, in one table.

It also ships Agent Skills — the portable SKILL.md format Claude Code, Codex, Cursor and OpenCode all read. Run bb skill install --global and your coding agent knows the --json contract, comment/reply flags, and exit codes — so it can read and reply to PR review comments itself, no browser needed.

One skill I lean on daily: a daily brief — one prompt, agent runs bb pr mine --build --json across every workspace, enriches only the candidates that matter, and ranks the rest. This is the real output shape:

``` 2 need you · 1 waiting on others · 1 quiet

🔴 YOU'RE BLOCKING acme/api PR 225 Validate mapi responses Your review is pending · 4h old → bb pr view 225 -R acme/api --unresolved --json

acme/web PR 206 Add guardrail hooks 💥 Build failed, changes requested by Dana · 5d old — oldest here → bb pr diff 206 -R acme/web

⏳ WAITING ON OTHERS acme/api PR 221 Dana hasn't replied to your 2 threads · 3d

✅ READY TO MERGE acme/api PR 198 Approved by Dana, build green · 2d

💤 1 quiet (1 draft) ```

Beats opening Bitbucket and scanning three tabs by hand.

Security model: API token lives in your OS keyring, never touches disk, never leaves api.bitbucket.org except for the (credential-free) update check against GitHub Releases.

Install: brew install biokraft/tap/bb, also on crates.io, cargo binstall, Nix flakes, or a checksum-verified install script. MSRV 1.88.

GitHub: https://github.com/biokraft/bbcloud

What would make this actually useful for your Bitbucket workflow? Taking feature requests.

Hey folks,

migration projects can be a pain, especially when you need to decide what to do with all the 3rd party apps installed on Jira and Confluence Data Center.

Atlassian already provides migration assessment tooling and App Usage, and those cover a good part of the picture.

I wanted to dig a bit deeper into the actual footprint that apps leave behind in an instance.

So I built two ScriptRunner endpoints, one for Jira Data Center and one for Confluence Data Center.

For Jira, the report looks at things like app-provided custom fields, how many issues actually carry values in those fields, screen and screen scheme placements, workflow references and app modules.

For Confluence, it inventories app modules and measures actual macro usage, with current and archived spaces reported separately.

The basic question is:

If we're considering removing or migrating this app, what detectable footprint does it still have in the instance?

The endpoints generate self-contained HTML reports, with JSON and CSV output available as well.

They don't try to measure clicks, views or general runtime activity. The idea is to complement Atlassian's existing tooling with another view of the current configuration and content footprint.

I've put the scripts on GitHub in case they're useful for anyone else doing DC assessments, app rationalisation or migrations:

https://github.com/cfaysal/atlassian-dc-app-footprint

It's still evolving, so feedback is very welcome.

I'd especially be interested in hearing from people who have done larger Jira or Confluence DC migrations:

• What app artefacts have caused surprises during assessments?
• What else would you want a footprint analysis like this to detect?
• Are there areas I'm currently missing that would be worth adding?

Issues and PRs are welcome as well.