Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Mar 19, 2026 2:11:55 AM
Nov 10, 2023 5:18:18 AM
This template was updated on December 4th, 2025 to replace the original installer and API key rotator with a new, unified deployer automation. Please disable or delete any existing installers, and create a new automation, picking the Qlik Cloud monitoring app deployer template from the App installers category.
Installing, upgrading, and managing the Qlik Cloud Monitoring Apps has just gotten a whole lot easier! With a single Qlik Automate template, you can now install and update the apps on a schedule with a set-and-forget installer using an out-of-the-box Qlik Automate template. It can also handle API key rotation required for the data connection, ensuring the data connection is always operational.
Some monitoring apps are designed for specific Qlik Cloud subscription types. Refer to the compatibility matrix within the Qlik Cloud Monitoring Apps repository.
This automation template is a set-and-forget template for managing the Qlik Cloud Monitoring Applications, including but not limited to the App Analyzer, Entitlement Analyzer, Reload Analyzer, and Access Evaluator applications. Leverage this automation template to quickly and easily install and update these or a subset of these applications with all their dependencies. The applications themselves are community-supported; and, they are provided through Qlik's Open-Source Software (OSS) GitHub and thus are subject to Qlik's open-source guidelines and policies.
For more information, refer to the GitHub repository.
Update just the configuration area to define how the automation runs, then test run, and set it on a weekly or monthly schedule as desired.
Configure the run mode of the template using 7 variable blocks
Users should review the following variables:
If the monitoring applications have been installed manually (i.e., not through this automation), then they will not be detected as existing. The automation will install new copies side-by-side. Any subsequent executions of the automation will detect the newly installed monitoring applications and check their versions, etc. This is due to the fact that the applications are tagged with "QCMA - {appName}" and "QCMA - {version}" during the installation process through the automation. Manually installed applications will not have these tags and therefore will not be detected.
Q: Can I re-run the installer to check if any of the monitoring applications are able to be upgraded to a later version?
A: Yes. The automation will update any managed apps that don't match the repository's manifest version.
Q: What if multiple people install monitoring applications in different spaces?
A: The template scopes the application's installation process to a managed space. It will scope the API key name to `QCMA – {spaceId}` of that managed space. This allows the template to install/update the monitoring applications across spaces and across users. If one user installs an application to “Space A” and then another user installs a different monitoring application to “Space A”, the template will see that a data connection and associated API key (in this case from another user) exists for that space already. It will install the application leveraging those pre-existing assets.
Q: What if a new monitoring application is released? Will the template provide the ability to install that application as well?
A: Yes, but an update of the template from the template picker will be required, since the applications are hard coded into the template. The automation will begin to fail with a notification an update is needed once a new version is available.
Q:I have updated my application, but I noticed that it did not preserve the history. Why is that?
A: Each upgrade may generate a new set of QVDs if the data models for the applications have changed due to bug fixes, updates, new features, etc. The history is preserved in the prior versions of the application’s QVDs, so the data is never deleted and can be loaded into the older version.
My entitlement analyzer app suddenly not able to refresh with below error.
any idea what causing the connection broken?
I also go to the Admin -> API keys -> checked the key still active and not yet expired
@htchan Make sure you've set up the a custom role to replace the now-removed Developer role (see Qlik Cloud Error: 401 Authorization Required after... - Qlik Community - 2534952). Then deploy the new monitoring apps using the new Qlik Cloud Monitoring Apps automation template as per this updated guide (the old one checks for a flag that no longer exists).
Hi all,
I just installed the updated monitoring apps through the new deployer automation (awesome work!).
What I notice is that the App Analyzer now takes almost 30 minutes to reload. The previous version took only a few minutes. My environment is quite large with a lot of apps, but I'm wondering if it is expected that the app takes a long time to reload.
Hi @fldc2500
In the last few versions the sheet usage was added, which in the three cases I've explored so far appears to be driving the increase. Do you happen to know which version you had prior to the update?
I'll ping you as well in case you can share with me the reload log.
Hello,
I realised that the Qlik Monitoring Apps Installer has changed since Dec 2025. When I try to connect to GitHub to download the installer, I get a 403 Forbidden error. I tried on multiple different computers, but the same thing is happening.
I am using https://github.com/qlik-oss/qlik-cloud-monitoring-apps this link but do not know how to download the installer.
I have been trying this for two days now. Can anyone please help?
Hi I've updated things on my tenant to use the new automation and it worked for 3 days but today I've got reload failures on a couple of Reload Analyser and Answers Analyser like this Invalid argument. (Connector error: Timeout when waiting for HTTP response from server. Increase the <Timeout> value in your settings.)
Looking at the connection, the timeout is set to 30. I've tried increasing it but the connection won't save because it's asking me for the API Key, which I don't know because it was set up during the automation run.
Help!
More thoughts on this timeout issue
1. I reloaded the 2 apps and it worked fine. Perhaps there's more load on the Qlik servers when everyone's monitoring apps reload at the default time in the morning? (By default all the monitoring apps reload concurrently at 06:15)
2. Changing the timeout in the connection wouldn't really work because the next time you run the automation it will delete/create a new connection with the timeout set to 30.
So... is the solution to set the timeout a bit higher, when the connection is created in the automation?
ChatGPT suggests editing the Raw API Request block that creates the connection to add these bits in bold. What do you think?
{ "dataSourceId": "rest", "qName": "monitor_api_rest", "space": "YOUR_SPACE_ID", "connectionProperties": { "url": "https://<tenant>/api/v1/users", "timeout": 900, "readTimeout": 900, "queryHeaders": [ { "name": "Authorization", "value": "Bearer <API_KEY>", "encrypt": true } ], "allowWithConnection": "true" } }
Or just to change the reload time away from 06:15 🙂
@sshastry the installer is a template within your tenant. You do not need to go to that repository. If you create a new Automation in your tenant, it'll open the template picker - you can find the template there.
@Dave_Channon - Haha. yes.. after I posted the comment, I figured that out - but truly appreciate you responding. The new version is much faster for sure. Thank you!!
@RoryMcHugh-Catalyst there are two things I want to add to the connection deployer, which is the read timeout, and the retry on 502s.
So...go for it and I'll get the template updated in the next fortnight.