Een collega was bezig met een aanpassing in de Qlik Cloud-omgeving van een klant. Door een fout in het laadscript werd data niet incrementeel geladen, maar volledig opnieuw ingelezen in een andere space. Hierdoor steeg het gebruik van Data for Analysis naar 54,27 GB, terwijl de klant een capaciteit van 50 GB heeft.

We ontdekten de fout en corrigeerden deze binnen ongeveer twee uur. Maar daarmee was de kous niet af. Ook een kortstondige overschrijding kan bij Qlik Cloud tot overagekosten leiden.

We kennen dit risico al langer en monitoren het capaciteitsverbruik van onze klanten actief. Toch konden we deze overschrijding niet voorkomen.

In dit geval nemen we de rekening voor onze rekening. De fout lag bij ons en het bedrag is te overzien. Maar wat als de overschrijding niet 5 GB was geweest, maar 50 of zelfs honderden GB’s?

Hoe werkt Qlik Cloud overage?

Bij de capacity-based abonnementen van Qlik Cloud betaal je voor een bepaalde hoeveelheid Data for Analysis. Ga je daar overheen, dan blijft je omgeving functioneren. De extra capaciteit wordt achteraf gefactureerd.

Qlik rekent daarbij op basis van de hoogste capaciteitsmeting van de maand. Of je nu twee uur of de hele maand boven je capaciteit zit, maakt voor de afrekening van die maand niet uit.

Hoe hoog die rekening kan worden, is misschien niet bij iedereen bekend.

Qlik Cloud Premium kost volgens de publieke prijslijst vanaf $2.750 per maand, inclusief 50 GB Data for Analysis. Op AWS Marketplace staat bovendien een overagetarief van $344 per 5 GB vermeld.

Op basis van dat publieke tarief kunnen we de volgende berekening maken:

Dit zijn indicatieve berekeningen op basis van de openbare AWS Marketplace-prijs. De daadwerkelijke kosten zijn afhankelijk van de toepasselijke overeenkomst.

Waarom die laatste 450 GB? Omdat Qlik toestaat dat je tot tienmaal je aangeschafte capaciteit verbruikt. Bij een abonnement van 50 GB betekent dat maximaal 500 GB totaal, waarvan 450 GB overage.

Een theoretische rekening van ruim $30.000 voor één maand dus, bij de minimale capaciteit van een Qlik Cloud Premium-abonnement.

Waarom kunnen klanten hun eigen grens niet instellen?

Wat ik vooral mis in het huidige model, is de mogelijkheid om zelf een grens aan het capaciteitsverbruik te stellen.

Bij Qlik Cloud Starter geldt een harde capaciteitsgrens: op is op. Bij Standard en Premium kun je tot tienmaal je aangeschafte capaciteit verbruiken. Er zijn dus al mechanismen om het verbruik te begrenzen, alleen kunnen klanten die grens niet zelf instellen.

Qlik bevestigde tijdens een Techspert Talks-sessie over capaciteitsmonitoring in mei 2026 dat klanten geen eigen limiet kunnen instellen voor Data for Analysis-verbruik. We hebben dit ook rechtstreeks bij Qlik nagevraagd en dezelfde bevestiging gekregen.

Ik begrijp de gedachte achter overage. Je wilt voorkomen dat een productieomgeving onverwacht stopt omdat een capaciteitsgrens wordt bereikt. Maar niet iedere organisatie zal daarin dezelfde afweging willen maken. De ene klant geeft de voorkeur aan maximale continuïteit, terwijl de andere liever het risico op onverwachte kosten beperkt.

Het zou mooi zijn als klanten die keuze zelf konden maken.

Wat kun je zelf doen?

Natuurlijk kun je zelf maatregelen nemen om het risico te beperken.

Bij Bitmetric houden we hier al langer rekening mee. We zijn bijvoorbeeld terughoudend met het adviseren van een overstap naar capacity-based abonnementen wanneer het datavolume onvoldoende voorspelbaar of beheersbaar is.

Qlik biedt zelf ook mogelijkheden om je capaciteitsverbruik te monitoren. Volgens het Qlik Cloud Administrator Playbook ontvangt de Service Account Owner waarschuwingen wanneer het verbruik 80%, 90% en 100% van de ingekochte capaciteit bereikt. Deze drempelwaarden en de ontvanger van de meldingen zijn echter niet aanpasbaar.

Dat laatste is een beperking. De Service Account Owner is niet altijd degene die het technisch beheer uitvoert, maar bijvoorbeeld iemand uit het management. Die kan de impact van een waarschuwing niet altijd direct beoordelen of actie ondernemen. Zeker bij een snel oplopend verbruik is het belangrijk dat een melding meteen bij de juiste persoon terechtkomt.

Voor meer gedetailleerd inzicht biedt Qlik de Detailed Consumption Reports. Daarmee kun je zien hoe je capaciteit wordt gebruikt en welke processen daaraan bijdragen. Met Qlik Automate kun je de rapportages bovendien automatisch laten distribueren.

Daarnaast monitoren we bij onze klanten met CloudScan for Qlik hoe het capaciteitsverbruik zich ontwikkelt. We analyseren de groeitrend en waarschuwen wanneer een tenant naar verwachting zijn capaciteitsgrens gaat bereiken. Zo kun je tijdig maatregelen nemen.

Maar monitoring heeft zijn beperkingen. De capaciteitsinformatie die Qlik beschikbaar stelt, wordt niet realtime bijgewerkt. Bovendien kan het verbruik bij een reload zo snel toenemen dat de waarschuwingsgrenzen worden gepasseerd voordat iemand kan ingrijpen. Tegen de tijd dat je een overschrijding constateert, kunnen de kosten dus al zijn ontstaan.

Bovendien hoeft een overschrijding niet eens het gevolg te zijn van een fout. Veel Qlik-omgevingen werken met incrementele loads om het dataverbruik te beperken. Maar soms is een volledige herlading noodzakelijk, bijvoorbeeld na een wijziging in het datamodel of een correctie van historische gegevens. Omdat ook de ingelezen data meetelt voor Data for Analysis, kan zo’n normale onderhoudsactie al tot een capaciteitsoverschrijding leiden.

Je kunt dus zorgvuldig ontwikkelen, testen en monitoren, maar daarmee voorkom je niet ieder incident.

En wie betaalt de rekening?

Er zit ook een vervelende commerciële kant aan dit verhaal, zeker voor Qlik-partners.

Wanneer licenties via een partner worden geleverd, kan de overagerekening bij die partner terechtkomen. Die moet vervolgens met de klant afspreken wie de kosten draagt.

In ons geval is dat duidelijk. Wij hebben de fout gemaakt en nemen de kosten voor onze rekening.

Maar wat als de oorzaak minder duidelijk is? Bijvoorbeeld wanneer een medewerker van de klant onbedoeld veel meer data laadt dan verwacht. Of wanneer de rekening geen honderden, maar duizenden dollars bedraagt?

De klant heeft ingestemd met de abonnementsvoorwaarden, maar zal niet altijd bereid zijn onverwachte kosten te betalen. Zo kan een technisch incident ook de relatie tussen klant en partner onder druk zetten.

Qlik scheldt volgens de openbare productvoorwaarden overagekosten gedurende de eerste zes maanden van een initiële capacity-based subscription kwijt. Voor incidentele overschrijdingen na die periode hebben we nog geen standaard coulanceregeling kunnen vinden. We hebben hierover navraag gedaan bij Qlik.

Natuurlijk kun je extra capaciteit aanschaffen. Maar dat is vooral zinvol wanneer je die structureel nodig hebt, niet wanneer een foutieve reload je gedurende twee uur boven je limiet brengt.

Geef klanten de keuze

Qlik presenteert zijn capacity-based model op de eigen website als een manier om voorspelbare kosten te bieden. Dat is ook een van de voordelen van dit model, maar onverwachte overagekosten kunnen die voorspelbaarheid behoorlijk onder druk zetten.

Ik begrijp waarom Qlik overage toestaat. Het voorkomt dat processen onverwacht worden onderbroken wanneer de beschikbare capaciteit wordt overschreden. Tegelijkertijd zou ik graag zien dat klanten zelf kunnen bepalen hoeveel extra verbruik ze willen toestaan.

Dat kan bijvoorbeeld door een instelbare grens van 100%, 110% of 125% van de ingekochte capaciteit aan te bieden, met de mogelijkheid om de huidige grens van tienmaal de capaciteit te behouden.

Daarnaast zou een soepelere omgang met kortstondige, incidentele overschrijdingen welkom zijn.

We hebben inmiddels een feature request ingediend in de Ideation Portal van Qlik, onder de titel Configurable Data for Analysis Overage Limits in Qlik Cloud, en het onderwerp ook rechtstreeks bij Qlik aangekaart.

Inmiddels hebben we vernomen dat Qlik werkt aan nieuwe functionaliteit onder de naam Usage Bank. Deze is ook aangekondigd in Qliks productupdate van oktober 2026. Mogelijk biedt dit mogelijkheden om het capaciteitsverbruik beter te begrenzen. Of Usage Bank daadwerkelijk instelbare limieten voor Data for Analysis-overage gaat bieden, is echter nog niet bevestigd. We zijn hierover in gesprek met Qlik Product Management.

Ik hoop dat deze ontwikkeling klanten uiteindelijk meer mogelijkheden biedt om zelf de afweging te maken tussen continuïteit en financiële risico’s.

We volgen de ontwikkelingen rondom Usage Bank en de mogelijkheden om overage te begrenzen op de voet. Zodra er meer duidelijkheid is vanuit Qlik, werken we dit artikel bij.

Barry Harmsen

Barry is oprichter van Bitmetric. Hij werkt al meer dan twintig jaar in data & analytics, als ontwikkelaar, architect, trainer en adviseur. Hij houdt van oplossingen die passen bij de organisatie en die mensen ook echt gebruiken. Hij is voormalig Qlik Luminary en Qlik Partner Ambassador. Lang geleden schreef hij mee aan QlikView for Developers.

Buiten zijn werk besteedt Barry zijn tijd aan zijn gezin, roeien, klussen en hobbyprojecten waar zijn gezin in wisselende mate enthousiast over is.

The post Qlik Cloud overage: wie bepaalt hoeveel risico je loopt? appeared first on Bitmetric.