The latter approach has several advantages. The decision making of the monitoring job is intentionally kept simple, with the only options being to abort the main task or to do noth-ing (i.e. continue the task). However, the decision criteria can be of arbitrary complexity, and can depend on quantities computable only after the main task is started. For instance, a common decision point in battery testing is when the capacity of the investigated battery cell drops below 80% of the capacity obtained from the first cycle after pre-treatment (i.e. after "formation cycles"). The exact first cycle capacity is not known a priori. While this criterium can easily be implemented using a job monitoring (Fig. )), it would require modification of the linear workflow shown in Fig. (a), as the first cycle is treated differently from every successive cycle. Perhaps the biggest advantage is in saving valuable instrument time: defective or poorly performing battery cells can be detected automatically and their study curtailed without human intervention. In view of battery research labs, where parallel cycling of several hundreds of cells is becoming common, the instrument time saved by job monitoring quickly becomes appreciable. Alternatively, the feature can be used to detect "steady states" in heterogeneous catalysis and thus accelerate catalytic testing workflows. The disadvantages of such approach are minor, but have to be considered. First, periodic data snapshots have to be available to AiiDA; this feature is implemented within tomato, but other schedulers might not support it. Second, in its current implementation, the job monitoring is performed on the same server where AiiDA is running, placing additional load on the hardware and increasing network traffic by repeated transfer of data snapshots; these issues can be alleviated by reducing the polling frequency of the monitoring job and by checksumming of snapshots. Finally, the monitoring job may abort the main task at an arbitrary point in its execution, leading to a poorly defined state of the sample (e.g. a state of partial charge); to account for this, judicious planning of the overall workflow is required, in our example achieved by implementing a final safety discharge task which is always executed.