Use trace logging when a Snowflake connection, timeout, or staged-file upload failure needs more detail than the task log provides. Enable it for a short reproduction, collect the files, then restore normal logging.

The instructions in this article apply to Snowflake ODBC 3.x, and the connection properties require Data Movement gateway 2024.5.54 or later. Snowflake ODBC 4.x uses a different logging configuration.

1. Prepare the log folder
   
   On the Qlik Data Movement gateway that performs the Snowflake ODBC operation, create the folder below. Confirm that the gateway service account can write to it and that there is enough free disk space. Record any existing logging values before changing them.
   
   /opt/qlik/gateway/movement/drivers/ODBC_Trace
   
   
2. Add the required connection properties to your Snowflake connection
   
   Edit the Snowflake connection. Expand Additional connection properties and use the plus button under ODBC properties to add the following three entries: 
   
   
   
   
   • LogLevel: 6 (Trace detail)
   • LogPath: /opt/qlik/gateway/movement/drivers/ODBC_Trace (Gateway folder for logs)
   • CURLVerboseMode: true (HTTP and TLS detail)
     
     
3. Reproduce and collect
   
   Save the connection. Stop and resume or rerun the affected task so it opens a new ODBC connection, then repeat the operation that failed. Note the task name and the reproduction time, including the time zone.
   
   Check your previously set log path on the Qlik Data Movement gateway for new or updated files.
   
   Typical names include the following; the exact set can vary:
   
   snowflake_odbc_driver.log
   snowflake_odbc_connection_0.log
   snowflake_odbc_generic0.log
   snowflake_odbc_curl.dmp
   
   Collect the driver logs and cURL dump together with the Qlik task log from the same attempt. Restrict access and review the files for sensitive data before sharing through your approved support channel.
   
   
4. Restore normal logging
   
   Restore the previous property values. If logging was previously off, set LogLevel to 0 and CURLVerboseMode to false.
   
   Save and rerun or resume the task with a new connection.
   
   Confirm that trace output has stopped. Keep tracing brief because detailed logs can grow quickly and affect performance.

Troubleshooting

If no logs appear

Check the executing gateway, folder existence and write permissions, available disk space, and whether a new ODBC connection was opened. A connection test alone may not exercise the failing upload. This guide enables Snowflake driver logging; unixODBC driver manager tracing uses separate settings.

Related Content

• Qlik Snowflake connection properties
• Snowflake ODBC logging parameters

It is possible to export the list of tenatnt users to a .json file using the "user ls" command from the Qlik Command Line Interface (qlik-cli).

Environment

• Qlik Cloud 

Resolution

The scripts provided in this article are provided as they are and they are for guidance only.   

As a tenant admin, download and configure the Qlik-cli 

1. run
   
   

   qlik user ls --limit 1000 > tenantusers.json​

   
   
   (please note: the qlik-cli is able to paginate over the limit of 100 users that concerns the API it uses. So, setting a higher limit will produce the full list of users). 
   
   in a command prompt or UNIX shell. The resulting tenantusers.json file will be saved in the current path for the prompt/shell  and will be in this format, with the roles defined on top and the user details under them.
   
   

   [
     {
       "assignedGroups": [],
       "assignedRoles": [
         {
           "id": "608050f7634644db3678b1a2",
           "level": "user",
           "name": "Developer",
           "type": "default"
         },
         {
           "id": "608050f7634644db3678b17f",
           "level": "admin",
           "name": "TenantAdmin",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af862",
           "level": "user",
           "name": "SharedSpaceCreator",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af866",
           "level": "user",
           "name": "ManagedSpaceCreator",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af86b",
           "level": "user",
           "name": "DataSpaceCreator",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af85d",
           "level": "admin",
           "name": "AnalyticsAdmin",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af85f",
           "level": "admin",
           "name": "DataAdmin",
           "type": "default"
         },
         {
           "id": "63580b8d5cf9728f19217be0",
           "level": "user",
           "name": "PrivateAnalyticsContentCreator",
           "type": "default"
         },
         {
           "id": "6356f0425cf9728f1962b942",
           "level": "user",
           "name": "DataServicesContributor",
           "type": "default"
         }
       ],
       "created": "2020-05-18T09:38:29.214Z",
       "createdAt": "2020-05-18T09:38:29.214Z",
       "email": "martina.testoni@dkdaklaldkdaklladaaddddl.com",
       "id": "USERID1",
       "lastUpdated": "2023-04-04T07:32:00.756Z",
       "lastUpdatedAt": "2023-04-04T07:32:00.756Z",
       "name": "Martina Testoni",
       "picture": "https://s.gravatar.com/avatar/gravatarimage=pg\u0026d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fdp.png",
       "preferredLocale": "",
       "preferredZoneinfo": "Europe/Copenhagen",
       "roles": [
         "Developer",
         "TenantAdmin",
         "SharedSpaceCreator",
         "ManagedSpaceCreator",
         "DataSpaceCreator",
         "AnalyticsAdmin",
         "DataAdmin",
         "PrivateAnalyticsContentCreator",
         "DataServicesContributor"
       ],
       "status": "active",
       "subject": "auth0|SUBJECTID2",
       "tenantId": "TENANTID"
     },
     {
       "assignedGroups": [],
       "assignedRoles": [
         {
           "id": "608050f7634644db3678b17f",
           "level": "admin",
           "name": "TenantAdmin",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af86b",
           "level": "user",
           "name": "DataSpaceCreator",
           "type": "default"
         },
         {
           "id": "608050f7634644db3678b1a2",
           "level": "user",
           "name": "Developer",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af866",
           "level": "user",
           "name": "ManagedSpaceCreator",
           "type": "default"
         },
         {
           "id": "63580b8d5cf9728f19217be0",
           "level": "user",
           "name": "PrivateAnalyticsContentCreator",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af862",
           "level": "user",
           "name": "SharedSpaceCreator",
           "type": "default"
         },
         {
           "id": "6356f0425cf9728f1962b95c",
           "level": "user",
           "name": "Steward",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af85d",
           "level": "admin",
           "name": "AnalyticsAdmin",
           "type": "default"
         },
         {
           "id": "62bb165356d1879582c1b468",
           "level": "admin",
           "name": "AuditAdmin",
           "type": "default"
         },
         {
           "id": "605a1c2151382ffc836af85f",
           "level": "admin",
           "name": "DataAdmin",
           "type": "default"
         }
       ],
       "created": "2023-03-31T08:44:37.332Z",
       "createdAt": "2023-03-31T08:44:37.332Z",
       "email": "Gentile.Faccenda@dkdaklaldkdaklladaaddddl.com",
       "id": "USERID2",
       "lastUpdated": "2023-04-03T11:24:35.037Z",
       "lastUpdatedAt": "2023-04-03T11:24:35.037Z",
       "name": "Gentile Faccenda",
       "picture": "https://s.gravatar.com/avatar/randomurl=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fdp.png",
       "roles": [
         "TenantAdmin",
         "DataSpaceCreator",
         "Developer",
         "ManagedSpaceCreator",
         "PrivateAnalyticsContentCreator",
         "SharedSpaceCreator",
         "Steward",
         "AnalyticsAdmin",
         "AuditAdmin",
         "DataAdmin"
       ],
       "status": "active",
       "subject": "auth0|IDPSUBJECT2",
       "tenantId": "TENANTID"
     }
   ]
   

    

2. Use any tool you like (online or not) to convert the json to csv, xlsx or other format. 
   
   In a PowerShell you can generate the users natively in csv format by using:
   
   

   qlik user ls --limit 1000 | ConvertFrom-Json | ConvertTo-Csv > tenantusers.csv​

Related Content

This article describes how to configure PostgreSQL 17 as both the source and target endpoint of a Qlik Replicate May 2026 task that uses Full Load and Apply Changes (change data capture, CDC). It follows a tested Windows setup from start to finish, and links to the Qlik Replicate documentation for the endpoint requirements. 

All configuration examples on third-party components (not Qlik Replicate) are provided as is and not covered by Qlik Support. Additional steps or customizations may be needed in your environment. 

Content

• Environment
• Prerequisites
• Prepare the PostgreSQL databases
• Create the source and target databases
• Enable logical replication on the source
• Create the replication account
• Allow the Qlik Replicate server to connect
• Set up DDL capture for a non-superuser account
• Prepare the Qlik Replicate server
• Prepare the target database
• Create the endpoints
• Create the source endpoint
• Create the target endpoint
• Create and run the replication task
• Verify the replication
• Verify the replicated tables
• Verify the control tables
• Validate change data capture
• Important considerations
• Related Content

Environment 

The example uses PostgreSQL 17 on Windows, with Qlik Replicate installed on a separate Windows server. The source and target databases can reside on the same PostgreSQL server for testing. Production environments typically use separate servers. 

• Qlik Replicate May 2026
• PostgreSQL 17 (source and target)
• Windows Server 

Example values used in this article: 

• Source database: source
• Target database: target
• PostgreSQL port: 5432
• Replication account: qlik_user
• Task type: Full Load and Apply Changes (CDC) 

Prerequisites 

• A PostgreSQL version supported by Qlik Replicate May 2026. See Supported source endpoints and Supported target endpoints.
• A PostgreSQL superuser account (for example, postgres) to create the databases, the replication account, and the DDL event trigger.
• Administrator access to the Qlik Replicate server to install client software and restart the Qlik Replicate service.
• Network access from the Qlik Replicate server to the PostgreSQL listener port (5432 in this example).
• An approved maintenance window. Changing wal_level requires a PostgreSQL restart.
• A review of Limitations and considerations (PostgreSQL source) and Limitations and considerations (PostgreSQL target). 

Prepare the PostgreSQL databases 

Create the source and target databases 

1. Connect to PostgreSQL as an administrator:

   psql -h <postgres_host> -p 5432 -U postgres -d postgres -W

2. Create both databases:

   CREATE DATABASE source;
   CREATE DATABASE target;

3. Confirm that both databases are listed:

   \l 

Enable logical replication on the source 

The required postgresql.conf values (wal_level, max_replication_slots, max_wal_senders, and the optional wal_sender_timeout) and the test_decoding output plugin are listed in Prerequisites (PostgreSQL source). Use the following steps to check and apply them. 

1. Connect to the source database as an administrator:

   \c source

2. Check the current settings:

   SHOW wal_level;
   SHOW max_replication_slots;
   SHOW max_wal_senders;

3. If wal_level returns replica, set it to logical:

   ALTER SYSTEM SET wal_level = 'logical';

4. Restart the PostgreSQL service during an approved maintenance window. For a Windows service named postgresql-17, run the following in an elevated Command Prompt:

   net stop postgresql-17
   net start postgresql-17

5. Reconnect, and confirm that SHOW wal_level; returns logical. 

Note: Changes to wal_level take effect only after a PostgreSQL restart. 

Create the replication account 

Qlik Replicate requires the superuser role for CDC, unless the account is set up as described in Using an account without the “superuser” role. This example uses a dedicated non-superuser account. For the full list of permissions, see Required permissions. 

1. In the source database, using an administrator account, create the role:

   CREATE ROLE qlik_user WITH LOGIN REPLICATION;

2. Set the password from psql:

   \password qlik_user

3. Allow the account to connect to the source database:

   GRANT CONNECT ON DATABASE source TO qlik_user;

4. Grant USAGE on the schema and SELECT on its tables, as documented in Using an account without the “superuser” role.
5. Optional: grant SELECT on tables that the postgres role creates in the future:

   ALTER DEFAULT PRIVILEGES FOR ROLE postgres
     IN SCHEMA public
     GRANT SELECT ON TABLES TO qlik_user;

   Default privileges apply only to objects created by the named role. If other roles create source tables, set their default privileges separately.
   
   
6. If the replication account creates the Qlik Replicate source-side artifacts in public, also grant schema creation:

   GRANT CREATE ON SCHEMA public TO qlik_user; 

Allow the Qlik Replicate server to connect 

Prerequisites (PostgreSQL source) describes the pg_hba.conf entry that the Qlik Replicate server requires, including the replication keyword. Use the following steps to verify the active configuration. 

1. Identify the active authentication file:

   SHOW hba_file;

2. Review the loaded rules, using an administrator account:

   SELECT line_number, type, database, user_name,
         address, auth_method, error
   FROM pg_hba_file_rules
   ORDER BY line_number; 

   A value in the error column indicates a rule that PostgreSQL could not load.
   
   
3. Confirm that a rule allows the replication account to reach the required databases from the Qlik Replicate server. For example, a restricted IPv4 rule:

   host source qlik_user <replicate_server_ip>/32 scram-sha-256

   Use the authentication method and network restrictions appropriate for your environment.
   
   
4. Confirm that PostgreSQL listens on the required interface and port:

   SHOW listen_addresses;
   SHOW port;

5. Verify that the firewall allows the Qlik Replicate server to reach the PostgreSQL port.

Note: Changes to pg_hba.conf require a configuration reload. Changes to listen_addresses require a PostgreSQL restart. 

Set up DDL capture for a non-superuser account 

A non-superuser account requires the attrep_ddl_audit table, the attrep_intercept_ddl() function, and the attrep_intercept_ddl event trigger. Create these objects, and grant the account access to the audit table and its sequence, exactly as described in Using an account without the “superuser” role. The event trigger must be created with a superuser account. 

If the objects are not in the public schema, enter their schema in the Create DDL artifacts in schema field on the source endpoint’s Advanced tab. See Setting advanced connection properties (PostgreSQL source). 

After completing the documented procedure, verify the event trigger: 

SELECT evtname, evtevent, evtenabled
FROM pg_event_trigger
WHERE evtname = 'attrep_intercept_ddl'; 

An enabled trigger returns: 

attrep_intercept_ddl | ddl_command_end | O 

Note: Do not grant permanent superuser privileges to the replication account only to bypass the DDL setup. 

Prepare the Qlik Replicate server 

1. On the Windows server where Qlik Replicate is installed, install the client software listed in Prerequisites (PostgreSQL target) and Prerequisites (PostgreSQL source).
2. Confirm that the folder containing psql.exe is in the Windows System PATH. For example:
   
   C:\Program Files\PostgreSQL\17\bin
   
   
3. Open a new Command Prompt on the Qlik Replicate server, and verify the client:

   where psql
   psql --version

   Example output:

   C:\Program Files\PostgreSQL\17\bin\psql.exe
   psql (PostgreSQL) 17.11

4. If the System PATH was modified, restart the Qlik Replicate service during a maintenance window, so that it picks up the updated environment. 

Prepare the target database 

The target account requirements are listed in Security requirements (PostgreSQL target). The grants below were used in this tested example, where Qlik Replicate creates and maintains the tables in the public schema of an existing target database. 

1. Using an administrator account, allow the account to connect to the target database:

   GRANT CONNECT ON DATABASE target TO qlik_user;

2. Connect to the target database:

   \c target

3. Allow the account to use and create objects in the schema:

   GRANT USAGE, CREATE ON SCHEMA public TO qlik_user;

4. If Qlik Replicate updates existing tables owned by another role, grant the required table-level privileges as well.

The exact privileges depend on the task settings, schema ownership, and selected target operations. 

Create the endpoints 

Create the source endpoint 

1. Create a PostgreSQL source endpoint as described in Setting general connection properties (PostgreSQL source). For this example, set Database name to source, and use the qlik_user credentials.
2. Configure SSL and the advanced connection properties as required for your environment.
3. Click Test Connection. 

A successful test confirms connectivity only. The task also requires the CDC prerequisites above to start successfully. 

Create the target endpoint 

1. Create a PostgreSQL target endpoint as described in Setting general connection properties (PostgreSQL target). For this example, set Database name to target.
2. Review the advanced connection properties, such as Max file size (KB) and XML Format, if required.
3. Click Test Connection.

Create and run the replication task 

1. Create a new task, and select the PostgreSQL source and target endpoints.
2. Enable Full Load and Apply Changes.
3. Select the source tables to replicate.
4. Review the target table preparation and control table settings.
5. Save the task.
6. Start the task with the appropriate run option. See Using the Run button options. 

Monitor the Full Load progress and the SOURCE_CAPTURE, TARGET_LOAD, and TARGET_APPLY log messages. 

Note: Use Fresh Start only for a new test task, or where resetting the existing replication state is acceptable. 

Verify the replication 

Verify the replicated tables

1. Connect to the target database:

   psql -h <target_host> -p 5432 -U postgres -d target -W

2. Confirm that the selected source tables exist:

   \dt public.*

3. Compare row counts and selected records with the source database. For example:

   SELECT COUNT(*) FROM public.customers;
   SELECT COUNT(*) FROM public.orders;
   SELECT COUNT(*) FROM public.products;

Verify the control tables 

The Apply Exceptions table (attrep_apply_exceptions) is always created. The other control tables depend on the task’s Control tables settings. 

1. Check which control tables exist:

   \dt public.attrep_*

2. Check their record counts:

   SELECT 'attrep_status' AS table_name, COUNT(*) AS row_count
   FROM public.attrep_status
   UNION ALL
   SELECT 'attrep_history', COUNT(*)
   FROM public.attrep_history
   UNION ALL
   SELECT 'attrep_ddl_history', COUNT(*)
   FROM public.attrep_ddl_history
   UNION ALL
   SELECT 'attrep_apply_exceptions', COUNT(*)
   FROM public.attrep_apply_exceptions
   UNION ALL
   SELECT 'attrep_suspended_tables', COUNT(*)
   FROM public.attrep_suspended_tables; 

Some control tables remain empty until the corresponding task event occurs. 

Validate change data capture 

After Full Load completes and the task enters change processing:

1. Run a controlled INSERT, UPDATE, and DELETE against a test table in the source database. For example:

   INSERT INTO public.customers
      (customer_id, customer_name, email, city) 
   VALUES 
      (9001, 'CDC Test', 'cdc@example.com', 'Denver');
   
   UPDATE public.customers
   SET city = 'Boston'
   WHERE customer_id = 9001;
   
   DELETE FROM public.customers
   WHERE customer_id = 9001;

2. Confirm that the target receives each change. To observe each intermediate state on the target, commit the operations separately, or pause between them.
3. Confirm the final state. In this example, the record with customer_id = 9001 no longer exists in the target after the DELETE is applied. 

Important considerations 

• Replication slots stay open after a task stops, and retain WAL until changes are acknowledged. Monitor WAL retention and slot activity, and remove unused slots manually, as noted in Prerequisites (PostgreSQL source). The WAL heartbeat option in Setting advanced connection properties (PostgreSQL source) helps keep the replication slot advancing.
• To remove the DDL capture objects after the task is retired, see Removing Replicate artifacts from the database.
• Before selecting tables, review Limitations and considerations (PostgreSQL target) and PostgreSQL Database target data types.
• The configuration in this article is a test example. Review security, sizing, networking, supported versions, and high availability (Setting up failover) before a production deployment.

Related Content 

• Using PostgreSQL as a source | Qlik Help
• Prerequisites (PostgreSQL source) | Qlik Help
• Required permissions | Qlik Help
• Using an account without the “superuser” role | Qlik Help
• Setting general connection properties (PostgreSQL source) | Qlik Help
• Setting advanced connection properties (PostgreSQL source) | Qlik Help
• Using a PostgreSQL-Based database as a target | Qlik Help
• Prerequisites (PostgreSQL target) | Qlik Help
• Limitations and considerations (PostgreSQL target) | Qlik Help
• Security requirements (PostgreSQL target) | Qlik Help
• PostgreSQL Database target data types | Qlik Help
• Setting general connection properties (PostgreSQL target) | Qlik Help
• Setting advanced connection properties (PostgreSQL target) | Qlik Help
• Control tables | Qlik Help 

This article describes how to manually move the Qlik Sense Repository Database from the PostgreSQL 14.x instance bundled with Qlik Sense Enterprise on Windows to a separately installed (unbundled) PostgreSQL 18 instance.

The procedure backs up the bundled instance, restores it into the new instance, and then removes the bundled database service.

This is the manual method otherwise executed by the Qlik PostgreSQL Installer. QPI currently does not support PostgreSQL 18. 

Content

• Prerequisites
• Preparation
• Backup
• Install PostgreSQL 18
• Prepare a backup folder
• Back up the existing database
• Restore the Qlik Sense backup to the PostgreSQL 18 instance
• Carry over the configuration
• Verify the database
• Test the environment (optional)
• Remove the old repository database service (required)
• Reinstall the PostgreSQL binaries
• Rename the old postgresql folder

Environment

• Qlik Sense Enterprise on Windows November 2025 and later
• Bundled Qlik Sense Repository Database on PostgreSQL 14.x
• PostgreSQL 18.x (new, unbundled instance)

Prerequisites

• Qlik Sense Enterprise on Windows November 2025 or later. Earlier versions are not compatible with PostgreSQL 18.x. See System requirements for Qlik Sense Enterprise.
• pgAdmin or DBeaver, to inspect the databases.
• Administrator access to the server hosting the Qlik Sense Repository Database.
• The password of the postgres superuser on the existing bundled instance.
• A maintenance window. All Qlik Sense services on all nodes are stopped during the backup.

Preparation

Backup

Perform a full backup of the Qlik Sense site, including the Qlik Sense Repository Database, the Qlik Sense share folder, and the Qlik Sense CA-signed certificates. See How To Take Backup And Restore Qlik Sense Enterprise on Windows.

Install PostgreSQL 18

1. Download and run the PostgreSQL installer from PostgreSQL downloads.
2. Install the new instance on the standard port 5432. The existing (bundled) instance stays on the Qlik Sense default port 4432.
3. Use the same superuser password as the existing instance.

Prepare a backup folder

Create an easily accessible backup folder. Example: C:\backup.

Back up the existing database

1. Stop all Qlik Sense services on all nodes. Leave the existing PostgreSQL service (Qlik Sense Repository Database) running.
2. Stop the new PostgreSQL service (e.g., postgresql-x64-18).
3. Open a command prompt as administrator.
4. Set the password:

   SET PGPASSWORD=your_postgres_password

5. Go to the existing version's bin folder:

   cd "C:\Program Files\Qlik\Sense\Repository\PostgreSQL\14\bin"

6. Dump the whole instance:

   pg_dumpall.exe -h localhost -U postgres -p 4432 -f c:\backup\backup_db.sql

7. Wait for the dump to finish.

If you are prompted for a password:

1. Edit C:\ProgramData\Qlik\Sense\Repository\PostgreSQL\14\pg_hba.conf and change md5 to trust.
2. Restart the existing PostgreSQL service.
3. Revert to md5 once the backup is complete.

Restore the Qlik Sense backup to the PostgreSQL 18 instance

1. Start the new PostgreSQL service (postgresql-x64-18).
2. Stop the existing (old) service (Qlik Sense Repository Database).
3. Open a command prompt as administrator.
4. Go to the new version's bin folder:

   cd "C:\Program Files\PostgreSQL\18\bin"

5. Restore the dump:

   psql -h localhost -U postgres -p 5432 -f c:\backup\backup_db.sql

If you get "password authentication failed for user postgres":

1. Edit C:\Program Files\PostgreSQL\18\data\pg_hba.conf and change scram-sha-256 to md5.
2. Restart the new PostgreSQL service and re-run the restore.

Carry over the configuration

Either copy the following two files from the old data folder into the new one:

• pg_hba.conf
• postgresql.conf

Or verify and modify both files manually: 

• In postgresql.conf: the port is 4432 (the Qlik Sense standard)
• In pg_hba.conf: 
  • IPv6 local connections are set to ::/0
  • Add the following line to the bottom of the file unless it already exists:

    host all all 0.0.0.0/0 md5

Verify the database

With pgAdmin or DBeaver, check that all of the following databases are present:

• Licenses
• QSMQ
• QSR
• SenseServices
• postgres

If any databases are missing, restore the dump once again, this time using port 4432:

psql -h localhost -U postgres -p 4432 -f c:\backup\backup_db.sql

After a successful restore, delete the PGPASSWORD environment variable.

SET PGPASSWORD=

Test the environment (optional)

Before you can begin testing, remove the Qlik Sense Repository Database dependency from the Qlik Sense Repository Service:

sc config QlikSenseRepositoryDatabase depend= /
sc config QlikSenseRepositoryService depend= /

After the dependency is removed:

1. Make sure the old Qlik Sense Repository Database service is stopped.
2. Restart the new PostgreSQL instance.
3. Start all Qlik Sense services.
4. Test your Qlik Sense setup thoroughly.

Remove the old repository database service (required)

Failing to remove the old service leads to upgrade or patching issues.

1. Browse to C:\ProgramData\Package Cache and search for the matching MSI: PostgreSQL14.msi
2. Right-click the MSI and select Uninstall.

Reinstall the PostgreSQL binaries

This is optional if you upgrade Qlik Sense immediately after unbundling the PostgreSQL database, since a Qlik Sense upgrade installs the correct binaries. But if you do not upgrade right away, reinstall the binaries immediately. Failing to do so will lead to service configuration script errors. 

1. In C:\ProgramData\Package Cache, find the MSI for your installed Qlik Sense version:
   • November 2026 and later: PostgreSQL18.msi
   • November 2025 to May 2026: PostgreSQL14.msi
2. Right-click the file, choose Open file location, and copy the folder path.
3. Open a command prompt as administrator and go to that folder:

   cd C:\ProgramData\Package Cache\{GUID}

4. Run the matching command. This installs the binaries without a database service.
   
   If Qlik Sense is installed in a custom directory, adjust INSTALLDIR (e.g., D:\Qlik\Sense).
   
   
   • November 2026 and later:

     msiexec.exe /qb /i "PostgreSQL18.msi" SKIPINSTALLDBSERVICE="1" INSTALLDIR="C:\Program Files\Qlik\Sense"

   • November 2025 to May 2026:

     msiexec.exe /qb /i "PostgreSQL14.msi" SKIPINSTALLDBSERVICE="1" INSTALLDIR="C:\Program Files\Qlik\Sense"

Rename the old postgresql folder

1. Using Windows Explorer, go to C:\Program Files\Qlik\Sense\Repository\PostgreSQL
2. Rename the folder 14 to 14.old

Qlik Cloud tenants are the highest level of logical isolation provided to our customers. The subscriptions and associated entitlements (also known as licenses) that customers purchase from Qlik are not fixed to these tenants. When needed, a customer can update the entitlement used by their tenant. This article covers how to do this, as well as all considerations before moving.

You should not attempt to update your tenant entitlement unless directed to do so by Qlik, or you are an OEM customer who is managing multiple entitlements for their estate.

The steps in this article only apply to User-Based Subscriptions. To convert your tenant from an evaluation tenant to a paid tenant, or to convert from a user-based subscription to a capacity-based subscription, contact Qlik Support.

Content:

• Why you might need to update your entitlement
• Considerations
• How to update the entitlement for your tenant
• 1. Retrieve the signed license key (SLK) for your entitlement
• 2. Export the current user assignments
• 3. Update the tenant entitlement
• 4. Reassign user assignments

Why you might need to update your entitlement

There are three scenarios where you might need to update your entitlement:

1. You have been directed to do so by Qlik support or another Qlik team
2. You are an OEM customer who purchased multiple subscriptions, and who wishes to merge these into your new multitenant entitlement
3. You are an OEM customer who is managing multiple multitenant entitlements

If you are an OEM or Enterprise customer leveraging multiple tenants in Qlik Cloud, please also consider reviewing the Platform Operations series on qlik.dev to learn more about managing these estates prior to changing your entitlements.

Considerations

Before you begin migrating your subscription or entitlement, consider:

• When changing entitlements, all assignments will be lost. This means any user who has previously been assigned a named entitlement (such as a professional-, analyzer-, full- or basic user entitlement) will need to have their entitlement reassigned. 
• Any entitlement changes are immediate. If your new entitlement is missing features or capabilities compared to the original entitlement, or it has less capacity than the original entitlement, then components in the tenant may not function as expected, or users may be impacted. As a good practice, verify the new entitlement on another tenant before applying the changes, or apply the change outside of working hours for the majority of your users.
• Original assignments are not restored if you re-apply the original entitlement. Although you are able to re-apply the original entitlement, it will not restore the original assignments, and some capabilities that may have been disabled through the move might need manually re-enabling.
• The Service Account Owner of the entitlement is the individual who has access to the tenant recovery capabilities. Make sure you know who the Service Account Owner is for the new entitlement before you move the tenant.

How to update the entitlement for your tenant

Updating the entitlement requires four steps:

1. Retrieve your signed license key 
2. Export the current user assignments
3. Update the tenant entitlement
4. Reassign  User assignments

1. Retrieve the signed license key (SLK) for your entitlement

Your SLK is available through:

• The welcome email sent when the entitlement was generated
• Qlik support, if you only have the numeric subscription or entitlement number available
• Any tenant already deployed to that entitlement
  
  To find the entitlement via an existing tenant, log into a tenant linked to the entitlement, and navigate to https://<hostname>.<region>.qlikcloud.com/api/v1/licenses/overview
  
  This will return a license definition, from which you can pull out the SLK. In the example below, you can see "licenseKey". We need the long value, e.g.: "eyJhbGciOiJSUzUxMiIsImtpZCI6ImE...".
  
  

  {"licenseNumber":"1234 5678 1234 5678","licenseKey":"eyJhbGciOiJSUzUxMiIsImtpZCI6ImEzMzdhZDE3LTk1ODctNG....","valid":"./2023-10-08","status":"Ok",...}

2. Export the current user assignments

When you migrate between entitlements, any user assignments will be reset. You will need to export any current assignments if you wish to reassign them. 

There are three ways of doing this:

1. Call the licenses/assignments API endpoint via script:
   
   

   curl -L -X GET 'https://<hostname>.<region>.qlikcloud.com/api/v1/licenses/assignments' \ -H 'Authorization: Bearer ey....' \ -H 'Content-type: application/json' \ -H 'Accept: application/json'

   
   
   
2. Log into the tenant you wish to bring onto the entitlement as a user with the Tenant Admin role. Then open the following address: https://<hostname>.<region>.qlikcloud.com/api/v1/licenses/assignments

   
   If you have many users, both option a and b will require you to paginate to get all results.
   
   Results will look like:

   {     "data": [         {             "subject": "QLIKBOT\\f0e92f326ac77427df155940fec39e6a",             "type": "professional",             "excess": false,             "created": "2022-10-20T13:46:29.474Z"         },         {             "subject": "auth0|a08d000001f0wjria3",             "type": "professional",             "excess": false,             "created": "2022-10-06T09:21:13.265Z"         },         {             "subject": "QLIKBOT\\52b7313d6705e2873eaadb9be23d8c06",             "type": "professional",             "excess": false,             "created": "2022-10-05T12:46:01.716Z"         }     ],     "links": {         "next": {             "href": ""         },         "prev": {             "href": ""         }     } }

   
   
   
3. Log into the tenant you wish to bring onto the new entitlement as a user with the Tenant Admin role, and use an automation to export these assignments. The example below returns the list as a table to the automation output. To import this automation, simply create a new automation, right click, then import the workspace JSON file attached to this post (automation-template-export-license-assignments.json).
   
   Output of attached automation template
   
   Note that for tenants with a large number of users, you will need to output the records to a file as the output window will eventually be capped.

3. Update the tenant entitlement

1. Log into the tenant you wish to bring onto the new entitlement as a user with the Tenant Admin role
2. Click your Profile
3. Click About
   
   
   
   
4. Click the key icon next to Subscription ID
   
   
   
   
5. Enter the SLK for the multitenant entitled subscription
   
   
   
   
6. Click Submit

4. Reassign user assignments

If required, reassign entitlements which were exported in step 2. You can do this in two ways:

1. Manually, by navigating to the management console.  See Assigning user entitlements | Help.qlik.com.
2. Programmatically by using automations or raw API calls.
   
   An example API call to assign an entitlement is shown below.
   
   Example cURL code to assign an entitlement (can also be done in automations):
   

   curl -L -X POST 'https://<hostname>.<region>.qlikcloud.com/api/v1/licenses/assignments/actions/add' \
   -H 'Authorization: Bearer ey...' \
   -H 'Content-type: application/json' \
   -H 'Accept: application/json' \
   --data-raw '{
       "add": [
           {
               "subject": "1ef2caed0dbe0a66a24ccadf61546099",
               "type": "professional"
           }
       ]
   }'

The information in this article is provided as-is and to be used at own discretion. Depending on tool(s) used, customization(s), and/or other factors ongoing support on the solution below may not be provided by Qlik Support.

Qlik Cloud Tenant Admins report that the IP Allowlist option is missing from Administration > Settings. In some cases, the Alerts submenu is also unavailable (existing alerts may still be visible, but create or edit is not possible).

The Feature Preview settings may also appear under an “Other” tab instead of their normal location. The issue affects multiple Tenant Admins in the same tenant and appears suddenly without any configuration changes in Qlik Cloud.

Environment:

• Qlik Cloud

Resolution

The missing menu options are caused by blocked outbound network calls to Qlik Cloud feature-flag and analytics services. When these calls fail, the user interface hides the related features.

1. Ask the network and security team to allowlist (or add to SSL inspection bypass) the following domains:
   • clientsdk.launchdarkly.com
   • app.launchdarkly.com
   • events.launchdarkly.com
   • cdn.pendo.io
   • pendo-static-5763789454311424.storage.googleapis.com
2. Refer to the official domain allowlisting documentation for the complete current list:
   Qlik Cloud – Domain allowlisting
3. After the domains have been allowed, perform a hard refresh of the browser (or clear cache and reopen the session).
4. Confirm that the IP Allowlist tab and Alerts options reappear in Administration.

This issue is almost always network-related (proxy / SSL interception / DLP) and not a change in Qlik Cloud itself. Testing from a different network (e.g. mobile hotspot or unrestricted network) can quickly confirm the diagnosis.

Cause

Qlik Cloud uses LaunchDarkly for feature flags and Pendo for in-product guidance and analytics. Several Administration features (including IP Allowlist and Alerts) depend on successful calls to these services.

When a corporate proxy, SSL inspection appliance, or Data Loss Prevention tool blocks or intercepts traffic to domains such as clientsdk.launchdarkly.com or Pendo endpoints, the browser receives no response (or a CORS/connection error). The Qlik Cloud frontend then falls back to a reduced feature set and hides the corresponding menu options.

This explains why the same tenant can show the full Administration menu from an unrestricted network while the options are missing when accessed from the corporate network.

Related Content

• Qlik Cloud DNS and IP allowlisting
• Managing IP allowlists in Qlik Cloud

A Talend Remote Engine running as a service on Linux repeatedly shows Unavailable in TMC during a consistent daily window (for example, 05:00 to 06:30 CST). The service appears healthy on the host, and no network issues are found. Scheduled tasks on the engine may fail or be skipped during this window.

Typical log indicators:

• wrapper.log: the JVM hung and was killed with SIGKILL, and the wrapper timed out waiting for Karaf to initialize.
• karaf.log / karaf-10.log: log back pressure (dropped log events) and tasks blocked by a parallel execution restriction.
• Permission denied errors when the engine writes to /var/lock/subsys/talend-remote-engine.
• The deployment limit is shown at its maximum (for example, 10/10).

Environment

• Talend Cloud

Resolution

1. Stagger the scheduled jobs that overlap in the affected window so fewer run concurrently. In this case, this stopped the Unavailable condition.
2. Review the deployment limit (max.deployed.flows). Raise it only if the host has capacity for additional JVMs. Otherwise, reduce the number of concurrent tasks per engine.
3. Monitor host resources (CPU, memory, swap, disk I/O) during the failure window. Check the health of any network mounts used as job sources.
4. If memory pressure is confirmed, increase the engine JVM heap via the Xmx setting in the wrapper configuration (the recommended heap for a Remote Engine running as a service is 1 GB), add host memory, or move some jobs to another engine.
5. Verify permissions on /var/lock/subsys/ so the Remote Engine service account has write access. Upgrade to the Remote Engine release that fixes the underlying bug when available.
6. Confirm the Remote Engine version and check whether the TMC false-unavailable edge case applies.
7. If the issue persists after these steps, open a new case with karaf.log, wrapper.log, job execution logs, and resource monitoring data for the failure window.

Cause

The most likely cause is JVM unresponsiveness under peak concurrent load. Many parallel jobs and large file transfers (around 100 MB archives) were scheduled in the same window. This can cause host resource contention (memory or swap pressure, prolonged garbage collection, or disk/network-mount I/O stalls). The wrapper then killed and restarted the engine JVM. While the engine reconnects, TMC marks it as Unavailable, even though the service eventually recovers by itself.

Related Content

• Qlik Talend Cloud: JVM Hanging Errors occur in Wrapper Log for Talend Remote Engine Server 
• Running tasks in parallel on Remote Engine 

Environment

• Talend Studio

In earlier versions of the cFile before Talend Studio version 2026-01, the success field was intentionally left blank to keep the file in its original location. After the migration, even if the success field is left intentionally blank, the component will create a ".camel" folder and move the successfully consumed file there.

Environment

• Talend Studio

Resolution

Caused by QAPPINT-3213.

Fix Version

QAPPINT-3213 is expected to be resolved in the Talend Studio R2026-11 release. Review the relevant release notes for details.

Workaround

No workaround is available. 

Cause

QAPPINT-3213 Cfile 2026-01 changes is forcing a file move when NOOP is disabled when it is successfully consumed

Internal Investigation ID(s)

QAPPINT-3213

Environment

• Talend Studio

The Scheduled Job icon in the Job Conductor section continues to display even after the job has completed. 

This behavior started after patching the Talend Administration Center to 2026-09.

Before patching, the Scheduled Job icon would disappear once the job was completed, and only the corresponding Job Completed or Job Failed icon would be displayed.

Resolution

This is caused by QTAC-3083.

Fix Version

QTAC-3083 is expected to be resolved in the November Talend Administration Center patch. Review the relevant release notes for details.

Workaround

No workaround is available. 

Cause

QTAC-3083 Timeline: scheduled events not removed after the scheduled run (regression from Quartz 2.5.x upgrade)

Internal Investigation ID(s)

QTAC-3083

Environment

• Taledn Administration Center

A Qlik Replicate task using an Amazon RDS for PostgreSQL source, with the supportCdcPartitionedTables internal parameter enabled, terminates with a broken connection. The SOURCE_CAPTURE log component reports:

Failed to get partition details about table <schema>.<tablename>
Failed to get parent table details of child table '<schema>.<tablename>'

The error can reference tables that are not included in the task. The task restarts automatically and resumes processing.

The partition error is a side effect, not a partitioning metadata failure. The SOURCE_CAPTURE log also records the underlying error, showing that the database connection was dropped:

RetCode: SQL_ERROR  SqlState: HY000 NativeError: 1 Message: FATAL:  terminating connection due to idle-session timeout SSL connection has been closed unexpectedly

The error can appear in every environment that shares the same source endpoint configuration.

Resolution

Add TCP/IP keepalive settings to the source endpoint

1. Open the Amazon RDS for PostgreSQL source endpoint in Qlik Replicate, and go to the Advanced tab.
2. Add the internal parameter additionalConnectionProperties, with the value:
   
   KeepaliveTime=60;KeepaliveInterval=1;

3. Save the Endpoint.
4. Resume the task.

For more information about Internal Parameters, see Qlik Replicate: How to set Internal Parameters and what are they for?.

Configure TCP/IP keepalive at the operating system level

On the Qlik Replicate server, set the operating system’s TCP keepalive interval to match, or be shorter than, the idle-session timeout enforced by the Amazon RDS for PostgreSQL instance or any intermediate firewall.

Cause

An idle-session timeout terminates the connection between Qlik Replicate and the Amazon RDS for PostgreSQL instance. The timeout can be enforced at the database level or by a network component, such as a firewall. The query that is running when the connection drops, in this case a partition-tree lookup, fails with an SSL connection error.

Related Content

• Qlik Replicate: How to set Internal Parameters and what are they for?

Internal Investigation ID(s)

SUPPORT-11452

Environment

• Qlik Replicate

With a Microsoft SQL Server source, Qlik Replicate tasks can miss transactions in one of two ways:

• Data loss during a task restart by timestamp: a task is stopped and then resumed using the start from timestamp option, and replication begins at a log sequence number (LSN) later than expected. Transactions committed at or near the restart boundary are skipped.
• Data loss in transit: transactions present in the SQL Server transaction log are not captured by the Qlik Replicate change data capture (CDC) task, even though no restart occurred.

In both cases, rows committed on the source are missing from the target, and the affected tables must be fully reloaded.

Resolution

Reduce data loss during task restart

1. Avoid start from timestamp as the restart method when precision is required, since it can produce an LSN start position that is later than expected.
2. If the replication user has sysadmin privileges on SQL Server, add the internal parameter afterConnectScript to the source endpoint, with the value DBCC TRACEON(2537). This lets Qlik Replicate read the inactive portion of the online transaction log, so the task can start further back in time when it recovers from a stop.
3. Set the internal parameter logScanBatchSize to a value lower than 1000.
4. Stop and then resume the task, so that the endpoint settings take effect.

For more information about Internal Parameters, see Qlik Replicate: How to set Internal Parameters and what are they for?.

Investigate missing transactions without a restart

If transactions in the SQL Server transaction log are not captured while the task runs without a restart, contact Qlik Support.

Cause

Starting a task by timestamp is not exact. The LSN that Qlik Replicate derives from the requested timestamp can be later than expected, so the task resumes after transactions that were committed around the restart point.

Related Content

• Qlik Replicate: How to set Internal Parameters and what are they for?

Internal Investigation ID(s)

SUPPORT-11536

Environment

• Qlik Replicate

When the issue is related to the web browser cache and the user does not want to clear all browser cache, then what is the right approach to delete the cache only for the specific site?

Clear site-specific cookies and cache in Chrome

To delete cookies and cache for a specific site in Google Chrome, follow the instructions given below:

1. At the top right, click on the ellipsis (three dots)
2. Open Settings
3. Click Privacy and security
4. Select Clear browsing data 
   
5. To clear the complete cache: Check all data you wish to clear and click Clear data (this clear data for all sites)
   
   Direct link: chrome://settings/clearBrowserData
   
   
   
   
6. To choose a site: From the Privacy and Security menu, select Site settings 
   
   Direct link: chrome://settings/content/all
   
   
   
   
7. Click View permissions and data stored across sites 
8. From there, locate the site you wish to clear (expand the main domain for subdomains) and click the trash bin. 
   
   
    

Clear site-specific data in Legacy Edge

1. Click on the ellipsis (three dots) button on the top-right corner, then on History > Manage History.
2. Select the web page data you would like to delete, then click on the X button to the right, and confirm.
3. To delete all cache, instead of Manage History, click on Clear browsing Data.
4. Then select what data to delete. 

Clear site-specific data in Firefox

1. Open Firefox and go to Firefox Menu > Settings.
2. Go to the Privacy & Security tab.
3. Scroll to locate Cookies and Site Data
4. Click Manage Data 
5. Select or search for the website from the list and click Remove Selected. 
6. In order to remove all data, in Cookies and Site Data, click on Clear Data and then Clear the specific data.

Clear site-specific data in Safari

1. Open Safari, select the gear icon (settings) and open Preference
2. Select Privacy 
3. Click Details
4. Search for the website you wish to clear the cookies for
5. Select remove

Clear site-specific cache in Internet Explorer 11

1. Launch Internet Explorer and navigate to the website for which you want to delete cookies and cache.
2. Press F12 to launch Developer Tools and go to the Network tab.
3. To clear cache for the current website, click on Clear cache button or press Ctrl + R.
4. To delete all cache, go to Internet Options, then under the General Tab > Browsing history, click Delete.
5. Then select what data to delete.
6. To delete files specific to a web site, click on View Files.

Clear site-specific data in Internet Explorer 8, 9, and 10

1. Launch Internet Explorer and navigate to the website for which you want to delete cookies and cache.
2. Press F12 to launch Developer Tools.
3. Click on Cache on the Developer Tools menu bar.
4. From the drop down menu, select “Clear browser cache for this domain”. This will clear all the cache specific to the currently open website.
5. Similarly, go to Cache > Clear cookies for domain in Developer Tools to clear cookies of the current website.

To expedite the investigation for Qlik Data Gateway - Direct Access cases, the following information is required.

Pre-requisites

• Verify the current installed version is the latest available from QMC in QCS. The version history is documented here:  Upgrading Qlik Data Gateway - Direct Access 
• Verify DG server specifications RAM\CPU meet minimum requirements. Setting up Qlik Data Gateway - Direct Access
• Confirm that the DG is a dedicated server and that no other Qlik or third-party products are installed. General limitations and considerations 
• Verify your DAG is in the best condition Qlik Data Gateway Direct Access: Basic Health Check

Mandatory Information

Without this information, Qlik Support cannot begin reviewing the issue.

• Tenant ID
• Data Gateway Logs (Ensure to zip and upload the entire logs folder)

C:\Program Files\Qlik\ConnectorAgent\data\logs​

• A copy of the configuration.properties file found in:

C:\ProgramData\Qlik\Gateway

• Windows Application and System event logs (Logs should cover the timeframe of the reported error, No other filtering should be applied). Events should be saved in .evtx format. How To collect Windows Event Logs
• The output from msinfo32 in .nfo format: How to gather additional hardware and system information from a Windows system by using MSInfo32
• If specific to an app, provide:
  • Tenant ID
  • App ID(s)
  • Reload ID(s)
  • Script logs from the specific app can be obtained from Reload History > Details from the hub
    Refer to How to find reload logs in Qlik Cloud for details on determining Reload IDs and collecting reload logs.
  • If multiple Qlik Data Gateways are configured, provide the Data Gateway ID from the Qlik Cloud Management Console.
• If specific to an incident (multiple app failures for a given time), indicate the date and time when the issue occurred. 

Environment

• Qlik Data Gateway - Direct Access,  all versions.

Qlik Sense Enterprise Client-Managed offers a range of Monitoring Applications that come pre-installed with the product.

Qlik Cloud offers the Data Capacity Reporting App for customers on a capacity subscription, and additionally customers can opt to leverage the Qlik Cloud Monitoring apps.

This article provides information on available apps for each platform.

Content:

• Qlik Cloud
• Data Capacity Reporting App
• Access Evaluator for Qlik Cloud
• Answers Analyzer for Qlik Cloud
• App Analyzer for Qlik Cloud
• Automation Analyzer for Qlik Cloud
• Entitlement Analyzer for Qlik Cloud
• Reload Analyzer for Qlik Cloud
• Report Analyzer for Qlik Cloud
• How to automate the Qlik Cloud Monitoring Apps
• Other Qlik Cloud Monitoring Apps
• OEM Dashboard for Qlik Cloud
• Monitoring Apps for Qlik Sense Enterprise on Windows
• Operations Monitor, License Monitor, and Content Monitor
• App Metadata Analyzer
• The Monitoring & Administration Topic Group
• Other Apps

Qlik Cloud

Data Capacity Reporting App

The Data Capacity Reporting App is a fully supported app distributed within the product. For more information, see Qlik Help.

You can automate daily distribution of the latest app using the Capacity consumption app deployer template in Qlik Automate.

Access Evaluator for Qlik Cloud

For more information, see Qlik Cloud Access Evaluator.

Answers Analyzer for Qlik Cloud

For more information, see Qlik Cloud Answers Analyzer.

App Analyzer for Qlik Cloud

For more information, see Qlik Cloud App Analyzer.

Automation Analyzer for Qlik Cloud

For more information, see Qlik Cloud Automation Analyzer.

Entitlement Analyzer for Qlik Cloud

The Entitlement Analyzer is a Qlik Sense application built for Qlik Cloud, which provides Entitlement usage overview for your Qlik Cloud tenant for user-based subscriptions.

The app provides:

• Which users are accessing which apps
• Consumption of Professional, Analyzer and Analyzer Capacity entitlements
• Whether you have the correct entitlements assigned to each of your users
• Where your Analyzer Capacity entitlements are being consumed, and forecasted usage

For more information, see The Entitlement Analyzer.

Reload Analyzer for Qlik Cloud

For more information, see Qlik Cloud Reload Analyzer.

Report Analyzer for Qlik Cloud

For more information, see Qlik Cloud Report Analyzer.

How to automate the Qlik Cloud Monitoring Apps

Do you want to automate the installation, upgrade, and management of your Qlik Cloud Monitoring apps? With the Qlik Cloud Monitoring Apps Workflow, made possible through Qlik's Application Automation, you can:

1. Install/update the apps with a fully guided, click-through installer using an out-of-the-box Qlik Application Automation template. 
2. Programmatically rotate the API key that is required for the data connection on a schedule using an out-of-the-box Qlik Application Automation template. This ensures that the data connection is always operational. 
3. Get alerted whenever a new version of a monitoring app is available using Qlik Data Alerts. 

For more information and usage instructions, see Qlik Cloud Monitoring Apps Workflow Guide.

Other Qlik Cloud Monitoring Apps

OEM Dashboard for Qlik Cloud

For more information and to download the app and usage instructions, see Qlik Cloud OEM Dashboard & Console Settings Collector.

With the exception of the Data Capacity Reporting App, all Qlik Cloud monitoring applications are provided as-is and are not supported by Qlik. Over time, the APIs and metrics used by the apps may change, so it is advised to monitor each repository for updates and to update the apps promptly when new versions are available.

If you have issues while using these apps, support is provided on a best-efforts basis by contributors to the repositories on GitHub.

Monitoring Apps for Qlik Sense Enterprise on Windows

Operations Monitor, License Monitor, and Content Monitor

The Operations Monitor loads service logs to populate charts covering the performance history of hardware utilization, active users, app sessions, results of reload tasks, and errors and warnings. It also tracks changes made in the QMC that affect the Operations Monitor. 

• Basic information can be found in Operations Monitor | help.qlik.com
• Detailed descriptions of sheets and visualizations are accessible in the About the Operations Monitor story available from the app overview page under Stories

The License Monitor loads service logs to populate charts and tables covering token allocation, usage of login and user passes, and errors and warnings.

• Basic information can be found in License Monitor | help.qlik.com  
• Detailed descriptions of sheets and visualizations are accessible in the About the License Monitor story available from the app overview page under Stories

The Content Monitor loads from the APIs and logs to present key metrics on the content, configuration, and usage of the platform, allowing administrators to understand the evolution and origin of specific behaviors of the platform.

• Basic information can be found in Content Monitor | help.qlik.com  
• Each sheet in the Content Monitor includes an About text box to describe its content. 
  

All three apps come pre-installed with Qlik Sense. 

Qlik Support can only be provided for Apps pre-installed with your latest version of Qlik Sense Enterprise on Windows. 

App Metadata Analyzer

The App Metadata Analyzer app provides a dashboard to analyze Qlik Sense application metadata across your Qlik Sense Enterprise deployment. It gives you a holistic view of all your Qlik Sense apps, including granular level detail of an app's data model and its resource utilization.

Basic information can be found here: 

App Metadata Analyzer (help.qlik.com)

For more details and best practices, see: 

App Metadata Analyzer (Admin Playbook)

The app comes pre-installed with Qlik Sense.

The Monitoring & Administration Topic Group

Looking to discuss the Monitoring Applications? Here we share key versions of the Sense Monitor Apps and the latest QV Governance Dashboard as well as discuss best practices, post video tutorials, and ask questions.

Monitoring & Administration 

Other Apps

LogAnalysis App: The Qlik Sense app for troubleshooting Qlik Sense Enterprise on Windows logs 
Sessions Monitor, Reloads-Monitor, Log-Monitor 
Connectors Log Analyzer 

All Other Apps are provided as-is and no ongoing support will be provided by Qlik Support.

This article explains how the initial extract and load process differs between legacy connectors and Qlik Talend Cloud native connectors, so you know what to expect from each.

Legacy connectors

For legacy connectors, the initial connection, extract, and load involved two major steps:

1. Metadata discovery through data sampling. Legacy connectors used data sampling to define the target schema. The larger the sample, the more accurate the generated schema. However, a large sample could require extracting most or all of the data, which could take up to several days before the target destination was created. Legacy connectors loaded the data extracted during sampling into a staging area, for use in the initial full load.
2. Initial full data load. If full data extraction was used during metadata discovery, this load was fast, because the data was loaded directly from the staging area.

Qlik Talend Cloud native connectors

Qlik Talend Cloud native connectors work differently. There is no separation between preparation and data load. When a connection to a SaaS application is made, Qlik Talend Cloud begins replicating both recent and historical data.

During connection setup, you choose the start date for historical data — either the default or a custom date. By default, the connector requests 12 months of history, controlled by the Start Date setting. This date can be changed to capture anywhere from a few months to several years of historical data.

It's expected for the first run of any new dataset to take longer than later runs. Qlik Talend Cloud must extract the full backlog of historical data, so that it can track changes over time in future runs, and then load that data into the target. Each phase — extraction and loading — has its own expected limitations.

The time a historical replication takes can be affected by the connector's API quota. API rate limits also play a part: source applications restrict how many requests can be made in a given period, so the connector can't continuously request everything at once, or send thousands of API calls per second. Some integrations, such as Salesforce and Marketo, use API quotas that limit API usage. Qlik's integrations are designed not to consume all of the available quota, but using the same API elsewhere can use up that quota.

Completing the initial extract and load can take hours, and sometimes days, depending on the amount of historical data, the API quota, and API rate limits.

After the initial extract and load is complete, subsequent loads are expected to be fast for connectors that support change data capture (CDC), using Qlik Talend Cloud's bookmark technology.

Key differences

Environment

• Qlik Talend Cloud

Starting with the release of Talend Studio R2026-10, Talend Studio adopts a new structured patching release model. For the original announcement, see Upcoming changes to the Talend Studio Lifecycle and Release Schedule.

Beginning with the Talend Studio R2026-10 release, two Patch Release options are available for Talend Studio:

• Monthly Releases: continue the traditional Talend Studio patching model.
• Support Releases: a Support Release (SR) is a lighter version of the monthly release that focuses on CVE and security fixes and excludes new features, allowing an upgrade without taking on new functionality.

The Patch Releases can be identified as follows:

See Update paths | Talend Installation Guide for an overview and supported update paths. When viewing, verify that you are looking at the correct version.

Monthly Releases

Monthly Releases continue the traditional Talend Studio patching model.

• Immediate access to new features, improvements, and previews.
• Continue using the same patch naming and versioning convention, RYYYY-MM. Examples: R2026-10, R2027-01, R2027-06.
• Patch updates, such as Java or Camel framework changes, require revalidation and republishing for multiple jobs.
• Monthly Releases are the only way to access preview features — for example, the Studio AI Assistant and new components (tAPIContract, tAPIOperations).
• Latest Monthly Release update site: https://update.talend.com/Studio/8/Updates/latest
• Specific Monthly Release update site pattern: https://update.talend.com/Studio/8/Updates/RYYYY-MM

Support Releases

A Support Release (SR) is a lighter version of the monthly release that focuses on CVE and security fixes and excludes new features, allowing an upgrade without taking on new functionality.

• Every October Monthly Release serves as the baseline for a new Support Release cycle (format: RYYYY-10-SRnn). The October patches are still Monthly Releases, and are applied as a standard patch.
• R2026-10 is the first baseline of the new patching lifecycle. The next 11 Support Releases (R2026-10-SR01 to SR11) are delivered monthly from November 2026 to September 2027.
• R2027-10 is the baseline for the next cycle, and so on every October. Talend Studio retains 8.0.1 versioning under the new lifecycle — for example, 8.0.1 R2026-10, 8.0.1 R2027-10.
• Patch installation to Talend Studio follows the same process as standard Monthly Releases.
• Patches address security and CVE maintenance. Security and critical fixes can be applied quickly, without touching features in production.
• With fewer changes included, validating and republishing jobs after a patch is generally faster for Support Releases.
• Unlike Monthly Releases, SR patches do not include new features.
• Support Releases use the naming convention RYYYY-10-SRnn:
  • RYYYY-10 identifies the baseline release (for example, R2026-10, R2027-10).
  • SRnn identifies the sequential Support Release number.
  • Examples: R2026-10-SR01 (November 2026), R2026-10-SR02 (December 2026).
• Latest Support Release update site: https://update.talend.com/Studio/8/Updates/latest-SR
• Specific Support Release update site pattern: https://update.talend.com/Studio/8/Updates/RYYYY-10-SRnn
  
  

Extended Support

• After 12 months, moving to the next baseline release (R2027-10) is recommended. Customers on the Support Release track who are unable to upgrade immediately have the option to stay on the Extended Support track for up to six additional months.
• Extended Support Releases follow the same naming and versioning convention as Support Releases (RYYYY-10-SRnn) — for example, R2026-10-SR12 and R2026-10-SR13.
• Extended Support Releases are provided only upon request. Although up to six releases are possible during the six-month window, typically only a couple of patches are issued.
• Extended Support Releases are limited to critical CVE remediation and severe production-blocking issues. Medium- and low-severity CVEs are not addressed.

Timeline

This timeline is projected; changes are possible.

Upgrade Paths

With the introduction of Monthly Releases and Support Releases, only specific upgrade paths are supported. The general rule with patching is to move forward. It is not possible to downgrade.

See Update paths | Talend Installation Guide for more information and a detailed table. When viewing, verify that you are looking at the correct version.

Supported Upgrade Paths

• Monthly Release → Monthly Release: customers on the Monthly Release track can upgrade to a newer Monthly Release.
• Support Release → Support Release: customers on the Support Release track can upgrade to newer Support Releases.
• Support Release → Monthly Release: customers on the Support Release track may move to a newer Monthly Release at any time. Once on the Monthly Release track, there is no way to revert to the Support Release track until the next annual baseline release.
• Monthly Release → Next Annual Cycle Support Release: moving from a Monthly Release to a Support Release is supported if the Support Release belongs to the next annual cycle (for example, a 2026 Monthly Release to a 2027 Support Release).
• R2024-05 or later is required to adopt the new lifecycle. Customers on R2024-04 or earlier must first upgrade to R2024-05 or later, then move to R2026-10 or higher.
• Extended Support Release → Next Annual Cycle Support Release: migrating from Extended Support to the next annual Support Release is supported. All cumulative fixes from the next Monthly Release baseline patch are applied after upgrading.

Unsupported Upgrade Paths

• Monthly Release → Support Release: once on the Monthly Release track, there is no reverting to a Support Release associated with the same baseline release. This path is only possible if the Support Release belongs to the next annual cycle.
• Support Release → Monthly Release (same month): upgrading from a Support Release to a Monthly Release released the same month is not possible.
• Monthly Release → Previous Monthly Release: Talend Studio does not allow rollback or downgrade of patching.
• Support Release → Previous Support Release: Talend Studio does not allow rollback or downgrade of patching.
• Old Monthly Release → New Monthly Track: Talend Studio versions R2024-04 and earlier can't be upgraded directly to R2026-10 or later. Use an intermediate patch jump for an existing installation, or install Talend Studio fresh.

Talend Runtime

Talend Runtime follows the same lifecycle model as Talend Studio:

• Monthly Releases: include new features, improvements, and updates to bundled components (for example Java or Apache Camel versions), as well as CVE fixes.
• Support Releases: focus on CVE and security fixes only, with no new features and no change to bundled framework versions. Baseline and cadence are the same as Studio (October baseline, SR01 to SR11, then Extended Support on request).
• Naming convention: same RYYYY-10-SRnn format.
• Upgrade rules are identical (forward only, no downgrade, no return to the Support track within the same cycle once on Monthly).

To limit revalidation of jobs, routes and services at each patch, use the same track for Talend Studio and Talend Runtime in a given environment.

Which Path to Choose?

• For customers with no constraints on adopting existing Talend Studio patches, the recommendation is to continue with the existing Monthly Release track, since it includes all CVE fixes and the latest features.
• Customers with longer QA and deployment cycles may prefer the Support Release track, since it allows staying current on CVE fixes with minimal changes to Talend Studio.

Delayed Sync allows client-managed products to operate without internet access before connectivity to Qlik's License Backend Server (LBE) is required. By default, new licenses provide 90 days of temporary offline access.

Delayed Sync has been available since April 2020. It is supported in the following products:

• Qlik Sense Enterprise on Windows April 2020 or later
• Qlik NPrinting April 2020 or later
• QlikView April 2019 or later 

For Delayed Sync to be possible, a portable Signed License Definition (SLD) needs to be retrieved. The product can then be activated using the portable SLD.

Delayed Sync is not a permanent offline solution. A connection to the license backend must be made within 90 days of new license creation (not license activation). If an extension or a more permanent solution is required, contact Qlik Support via Chat or by raising a case via Support portal before the 90 days are reached. The 90 period will not reset. See Request license off-line approval - April 2020 and onwards for details on how to move to a permanent solution.

 

For old license which needs an extension on the temporary offline feature (Delayed Sync) do reach out to Qlik Support via Chat or by raising a case via Support portal.

When the connection to the LBE is made, the SLD will be automatically updated to SLK.

Prerequisites

• Qlik Sense Enterprise April 2020, Qlik NPrinting April 2020, and QlikView (April 2019 or later installed and ready to license
• The license must include the attribute: DELAYED_SYNC;YES;;[enddate] or OFFLINE;YES;;

Steps:

Step 1: Retrieve the portable Signed License Definition 

The SLD needs to be retrieved from the license backend server. Internet connectivity is required. To obtain the definition, use: Retrieve using Get Signed License Definition link

If you receive the error Unauthorized or Invalid SLK, verify that you have copied the Signed License Key correctly. Missing letters, extra letters, or unexpected linebreaks are the most common root cause.

Step 2: Activate the product using the SLD

The example provided uses the April 2020 Release of Qlik Sense Enterprise on Windows. Qlik NPrinting and QlikView function identically, though the license SLD will need to be applied in the individual product's license field.

1. Open up the Qlik Sense Management Console and when prompted, insert the Signed License Key (SLK).
   
   If port 443 is not open or no internet connectivity is available, the following error will appear:
   
   
   
    
2. Delete the SLK from the text box in the Qlik Sense Enterprise Management Console site license page
   
   
3. Paste the full SLD (previously retrieved using either Postman or PowerShell) in the same text box and click Apply.
   
   
   
   
4. The license will be applied once the message Successfully Updated appears in a green banner (as below):
   
   
   

Related Content:

Qlik License Service: the advantages of QLS activation
Viewing Qlik Sense license definition allotments using PowerShell

After a Stop and Resume operation on a Qlik Replicate Log Stream task with an IBM Db2 for i source, a subset of tables begins receiving NULL values in the RRN column.

When RRN is configured as the primary key for those tables, downstream merge processes fail with errors similar to:

DML operation to table DB2I_TABLE failed on column RRN with error:
NULL result in a non-nullable column

Environment

• Qlik Replicate

Resolution

1. Confirm that the Log Stream parent task's source endpoint is configured with Add RRN column to tables without a Primary Key or Unique Index rather than Add RRN column to all tables. This mismatch is the source of the NULL RRN values.
2. Because the parent task is current, and changing the endpoint setting would affect every table in the task, remove the affected tables from the existing parent/child task set.
3. Create a new source endpoint with Add RRN column to all tables enabled.
4. Create a new parent task using the new endpoint.
5. Create corresponding child tasks targeting the same Snowflake target tables.
6. Reload the affected tables within the new task to re-establish correct RRN population.
7. Confirm that data flows correctly, and that RRN values are no longer NULL.

Cause

The Log Stream parent task's source endpoint has the RRN setting configured as Add RRN column to tables without a Primary Key or Unique Index, instead of Add RRN column to all tables.

This misconfiguration causes RRN values to be NULL for the tables processed by the affected parent task, while other parent tasks with the correct setting continue to populate RRN correctly.

Internal Investigation ID(s)

SUPPORT-11485