A colleague was making a change in a customer’s Qlik Cloud environment. Due to an error in the load script, the data was not loaded incrementally but was reloaded in full into another space. As a result, Data for Analysis usage rose to 54.27 GB, while the customer has a capacity of 50 GB.

We discovered the error and corrected it within about two hours. But that was not the end of the matter. Even a brief capacity overage can result in overage charges in Qlik Cloud.

We have been aware of this risk for some time and actively monitor our customers’ capacity usage. Even so, we could not prevent this overage.

In this case, we will cover the bill. The mistake was ours, and the cost is relatively modest. But what if the overage had not been 5 GB, but 50 or even hundreds of GB?

How does Qlik Cloud overage work?

With Qlik Cloud’s capacity-based subscriptions, you pay for a certain amount of Data for Analysis. If you exceed that amount, your environment continues to operate. The additional capacity is billed afterward.

Qlik calculates this based on the highest capacity measurement of the month. Whether you exceed your capacity for two hours or the entire month makes no difference to that month’s bill.

Not everyone may be aware of how high that bill can be.

According to the public price list, Qlik Cloud Premium starts at $2,750 per month, including 50 GB of Data for Analysis. AWS Marketplace also lists an overage rate of $344 per 5 GB.

Based on that public rate, we can make the following calculation:

These are indicative calculations based on the public AWS Marketplace price. Actual costs depend on the applicable agreement.

Why the last 450 GB? Because Qlik allows you to use up to ten times your purchased capacity. With a 50 GB subscription, that means a maximum of 500 GB in total, of which 450 GB is overage.

That means a theoretical bill of more than $30,000 for a single month at the minimum capacity of a Qlik Cloud Premium subscription.

Why can’t customers set their own limit?

What I miss most in the current model is the ability to set your own limit on capacity consumption.

Qlik Cloud Starter has a hard capacity limit: once it’s used up, that’s it. With Standard and Premium, you can consume up to ten times your purchased capacity. So mechanisms to limit consumption already exist, but customers cannot set that limit themselves.

During a Techspert Talks session on capacity monitoring in May 2026, Qlik confirmed that customers cannot set their own limits on Data for Analysis consumption. We also raised this question directly with Qlik and received the same confirmation.

I understand the reasoning behind overage. You want to prevent a production environment from unexpectedly stopping because it has reached a capacity limit. But not every organization will want to make the same trade-off. One customer may prefer maximum continuity, while another would rather limit the risk of unexpected costs.

Customers should be able to make that choice themselves.

What can you do yourself?

Of course, you can take steps yourself to limit the risk.

At Bitmetric, we have been taking this into account for some time. For example, we are cautious about recommending a move to capacity-based subscriptions when data volume is not sufficiently predictable or manageable.

Qlik also provides options for monitoring your capacity consumption. According to the Qlik Cloud Administrator Playbook, the Service Account Owner receives warnings when consumption reaches 80%, 90%, and 100% of the purchased capacity. However, neither the thresholds nor the recipients of these notifications can be configured.

This is an important limitation. The Service Account Owner is not necessarily the person responsible for technical administration. It might be someone in management who cannot immediately assess the impact of a warning or take the necessary action. Especially when consumption increases rapidly, these alerts need to reach the right people without delay.

For more detailed insights, Qlik provides the Detailed Consumption Reports. These show how your capacity is being used and which processes contribute to that consumption. With Qlik Automate, you can also have the reports distributed automatically.

In addition, we use CloudScan for Qlik to monitor how our customers’ capacity consumption develops. We analyze the growth trend and issue a warning when a tenant is expected to reach its capacity limit. This allows you to take timely action.

But monitoring has its limitations. The capacity information provided by Qlik is not updated in real time. Moreover, consumption can increase so rapidly during a reload that warning thresholds are crossed before anyone has a chance to intervene. By the time you detect an unexpected overage, the costs may already have been incurred.

An overage does not necessarily have to result from an error, either. Many Qlik environments use incremental loads to limit data consumption. But sometimes a full reload is necessary, for example after a change to the data model or a correction to historical data. Because loaded data also counts toward Data for Analysis, a routine maintenance task like this can be enough to cause a capacity overage.

So you can develop, test, and monitor carefully, but that will not prevent every incident.

And who pays the bill?

There is also an uncomfortable commercial side to this story, especially for Qlik partners.

When licenses are provided through a partner, the overage bill may go to that partner. The partner must then agree with the customer on who will cover the costs.

In our case, it is clear. We made the mistake and will cover the costs.

But what if the cause is less clear? For example, when one of the customer’s employees unintentionally loads far more data than expected. Or when the bill amounts to thousands rather than hundreds of dollars?

The customer agreed to the subscription terms, but may not always be willing to pay unexpected costs. A technical incident can therefore also put the relationship between customer and partner under strain.

According to its public product terms, Qlik waives overage charges during the first six months of an initial capacity-based subscription. We have not yet found a standard goodwill policy for occasional overages after that period. We have asked Qlik about this.

Of course, you can purchase additional capacity. But that mainly makes sense when you need it on an ongoing basis, not when an incorrect reload puts you over your limit for two hours.

Give customers a choice

Qlik presents its capacity-based model on its website as a way to provide predictable costs. That is indeed one of the benefits of this model, but unexpected overage charges can put that predictability under considerable pressure.

I understand why Qlik allows overage. It prevents processes from being interrupted unexpectedly when the available capacity is exceeded. At the same time, I would like customers to be able to decide for themselves how much additional usage they want to allow.

For example, this could be done by offering a configurable limit of 100%, 110%, or 125% of the purchased capacity, with the option to retain the current limit of ten times the capacity.

A more flexible approach to brief, occasional overages would also be welcome.

We have now submitted a feature request in Qlik’s Ideation Portal, titled Configurable Data for Analysis Overage Limits in Qlik Cloud, and have also raised the issue directly with Qlik.

We have since learned that Qlik is working on new functionality called Usage Bank. It was also announced in Qlik’s October 2026 product update. This may offer ways to better limit capacity usage. However, it has not yet been confirmed whether Usage Bank will actually provide configurable limits for Data for Analysis overage. We are discussing this with Qlik Product Management.

I hope this development will ultimately give customers more options to make their own trade-off between continuity and financial risk.

We are closely monitoring developments around Usage Bank and the options for limiting overage. As soon as Qlik provides more clarity, we will update this article.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years as a developer, architect, trainer, and consultant. He likes solutions that fit the organization and that people actually use. He is a former Qlik Luminary and Qlik Partner Ambassador. A long time ago, he co-authored QlikView for Developers.

Outside of work, Barry spends his time with his family, rowing, doing DIY projects, and working on hobby projects that receive varying levels of enthusiasm from his family.

The post Qlik Cloud overage: who decides how much risk you face? appeared first on Bitmetric.