When “Peak Billing” Comes Knocking: How to Manage Atlassian’s New Pricing with Smarter Sharing
If you are not living under a stone, you must have heard about Atlassian’s new pricing model. This October, they introduced the “maximum quantity billing” (MQB) - a major shift in how customers are billed. This change is intended to provide more predictable costs and simpler tracking for budgeting and planning. But, at the same time, customers will need to manage user licenses carefully to optimize costs, especially if user counts fluctuate frequently within a month.
Under MQB, your monthly invoice will be based on the highest number of active users during that billing period, not your user count at the end of the cycle. That means if you briefly onboard contractors, external reviewers, or temporary collaborators mid-month, you will pay for those extra seats - even if most of your users drop off by month’s end. And removing users mid-cycle won’t reduce your current bill - you simply won’t get credits for unused seats, the new lower count only affects the next cycle. Check those examples to better understand the new rules.
Atlassian is applying this to core apps (Jira, Confluence, JSM, Compass) and Marketplace apps alike. The rationale? Simpler billing, more predictability, or a model that more tightly couples cost to growth spikes. But many organizations run variable workloads, and those spikes may be short-lived or unplanned.
Why this change stings more in “spiky” environments
If your user base is relatively stable (especially internal employees), MQB may be manageable. But many teams also involve ad hoc contributors - clients, external reviewers, partners, consultants, contractors, freelancers, or temporary teams. Inviting them to your instance, even briefly, now has a cost consequence tied to your peak usage.
Scenarios where this bites:
-
You bring external partners in to review or comment on tasks or documents.
-
You run pilot projects or short-term collaborations with contractors.
-
You frequently share data or documentation with external stakeholders who don’t need permanent user accounts.
Under the new billing model, those temporary additions can increase your “peak user” number for the cycle, and you have to pay extra for them.
Smart mitigation: use share-without-license tools instead
One way to reduce your exposure under MQB is to avoid giving full user seats to temporary collaborators. Instead of inviting them as licensed users, use tools that let you share content securely without adding them to your user pool. That’s exactly the role External Share for Jira and External Share for Confluence play.
These tools allow you to:
-
Share individual work items, boards, filters, timelines (in Jira), or pages, pages with child pages, attachments (for Confluence) with external users without onboarding them as full users.
-
Control permissions (view, comment, attach, edit) granularly, set share expiration time, restrict IPs or domains, or require passwords - all for enhanced security.
-
Keep real-time, bidirectional editing or commenting, without giving full access to your instance or space.
And the best part? You won’t pay a single dime for additional seats. By offloading external access into a sharing mechanism, you can better control when and how those users affect your billing footprint.
How this strategy plays out in practice
| Situation | Traditional (invite licensed users) | Using External Share |
|---|---|---|
| External reviewer for 2 weeks | Add full user seat → count toward peak | Share just the relevant task/page → no license needed |
| Client needs access to content to be able to provide input/feedback | Grant the client a user seat | Use External Share to allow commenting |
| Temporary workers/freelancers collaborating on a given project | Add them as users → license cost spikes | Share content as needed with full edit permissions via External Share |
| Document sharing for the external knowledge base | Give users Confluence access or make the content public | Publish pages with anyone - additionally, you can create another share with edit permissions to a certain group |
In each case, the “share not seat” approach helps contain artificially inflated peaks in your user count.
Advantages of Using External Share Apps
-
Cost Predictability and Reduction:
By limiting licensed users to internal team members only, you avoid spikes in monthly billing due to external collaborators who are transient or temporary users. -
Simplified User Management:
Managing fewer licensed seats internally reduces administrative overhead. You don’t need to provision or deprovision licenses for external users who only require limited access. -
Security and Control:
External Share apps often come with advanced permissions and sharing controls, allowing you to restrict what external users can see and do, enhancing data security compared to granting full user licenses. -
Business Continuity and Collaboration:
External users get seamless access to the latest project information, reducing communication barriers without costly license commitments, and enhancing collaboration efficiency. -
Monitor usage closely:
Watch your usage dashboard regularly- check every share created and all activities made on the shared content.
Conclusion: leaner collaboration, thinner spikes
Atlassian’s move to maximum quantity billing is not inherently bad - but it changes the economics of how you invite and manage external collaborators. If you treat every temporary user as a full user, your bill may balloon.
By adopting a share-not-seat mindset via tools like External Share for Jira and External Share for Confluence , you can continue involving external participants without needlessly increasing your billed user quantity. It’s a smarter way to deliver open collaboration and cost control.
Want help assessing your user growth patterns or architecting a share-based access model? Don’t hesitate to contact us , we’ll be happy to help 😉