Qlik Community


Search or browse our knowledge base to find answers to your questions ranging from account questions to troubleshooting error messages. The content is curated and updated by our global Support team

Support Case Portal has moved to Qlik Community! Read the FAQs to start exploring Support resources.

QlikView Tasks and reloads do not trigger, are queued, or give wrong status

Digital Support
Digital Support

QlikView Tasks and reloads do not trigger, are queued, or give wrong status

  • QlikView scheduled tasks are not triggering as expected
  • Schedules and task chains fail
  • Tasks are listed as in Queued status
  • QMC shows wrong task status 

After an upgrade to QlikView 12, the disk may not be able to handle the increased traffic compared from QlikView 11 to QlikView 12. 


  • Qlikview 12.10 and higher


Sanity Check

QlikView 12.10 introduced a feature called Overload Protection. Please first review the article Tasks are not executed as expected and are shown in status Queued to confirm if this is the behavior you are experiencing, as this could simply be working-as-expected behavior.

It may be worth verifying how many concurrent reloads are allowed in the system. See How many reload engines (QVB) to allow in an environment for details.

File Share and Disk 

The Windows File share the QlikView Distribution Service uses as its Root folder, the ApplicationData folder set in the QMC, is being overloaded. The ApplicationData folder hosts the trigger information, notification files, and historic data. This can affect an entire QlikView Distribution Service cluster and will occur more frequently if many tasks contain a Distribution either to the QlikView server or to a folder. 

See QlikView and its backend File Share System for background information on the above.

If the sanity check above does not apply (tasks should trigger, the CPU is not overloaded), the following may need to be done to fine-tune the system:

Move the Notification Folder

If a higher-performance disk is available (such as an SSD, optimized for higher levels of traffic), an easy troubleshooting step is to change the location of those high-traffic XML files to that disk. This can be done by:

  1. Shut down all Qlikview services on all nodes
  2. Add this under ************Misc Settings***********
<!-- Notification System alternate location, must be identical for all nodes in the cluster-->
<add key="NotificationFolder" value="\\UNCPATHTOLOCATION\"/> to QVDistributionService.exe.config on all Qlikview Distribution service nodes

       3. Restart all Qlikview services on all nodes If this resolves the issue, then this confirms the disk currently used to host the Notification Folder.


Lowering simultaneous file handles to update the file system

See QlikView Distribution Service / Publisher (QDS) high CPU usage without active tasks for instructions. 

Move the temporary storage of QlikView files for distribution

See QlikView: How to change the temporary storage of QlikView documents created before a distribution


Analytical Approach

If a high-performance disk is not available for testing, then the other option is to analyze the disk traffic with Windows Performance Monitor. Examine the Avg. Disk sec/Transfer and the Avg. Disk sec/Read disk metrics, and use a guide such as this one, which discusses general metrics for disk i/o to judge if the disk is exhausted.

Review the below to monitor the system:


Related Root Causes:

QlikView 12 - Task randomly skip trigger



Overload Protection may prevent tasks from executing due to CPU usage being above a threshold.

 One of the changes that was introduced in QlikView 12.10 and up is a re-factored Notification system for the Distribution Service, where we now access more files in parallel to avoid an old problem in using a cascading Notification system which would lead to a build-up of updates needing to ripple through the file system. 

The Notification system is where Task statuses are recorded, updated and retrieved by the QDSes and the Management Console. The  QDSes might face issues recording the status changes correctly and end up in a status where it cannot run any more tasks because it is unable to clear that statuses of the ones already completed. We know this change to have caused the same type of behavior in other customer environments, as it now exposes any file system latency in a different way. 

Labels (1)
Version history
Revision #:
3 of 3
Last update:
‎2020-11-09 11:37 AM
Updated by: