# Nextflow errorStrategy maxRetries: Step-by-Step Guide By the end of this guide you will be able to configure `errorStrategy 'retry'` and `maxRetries` in your Nextflow processes, scale compute resources automatically on each retry attempt, decide which exit codes deserve a retry and which should stop the run, verify that retries actually happened, and diagnose a task that failed even after all retries were used. These are the skills that separate a pipeline that dies at 3 a.m. on a shared cluster from one that recovers on its own and produces a complete, reproducible result. What you need on hand before starting: - A recent Nextflow installation (Nextflow runs on Java 17 or newer on current releases, so install Java 17 if your system does not already have it) - Write access to a work directory on the machine or cluster where you run the pipeline - A container engine such as Docker, Apptainer, or Singularity if your pipeline depends on containerized tools, which is the norm for modern published workflows [1] - A terminal with a text editor The examples below are self-contained. You can run them on a laptop with no scheduler at all, then apply the same directives on SLURM, LSF, or any other executor that Nextflow supports. ## What errorStrategy and maxRetries actually control In Nextflow, a **task** is one execution of one process, for example one alignment job for one sample. When a task's script exits with a nonzero status, Nextflow treats the task as failed. The `errorStrategy` directive tells Nextflow what to do about that failure, and it takes one of three values by default: | Value | Behavior | |--|--| | `terminate` | The default. The task fails and the whole run stops. | | `retry` | The task is executed again, up to the number of times set by `maxRetries`. | | `ignore` | The task failure is reported but the run continues as if the task had produced output. | `maxRetries` sets how many retry attempts a task is allowed when `errorStrategy` is `retry`. If you set `maxRetries 2`, a task gets its first execution plus up to two retries, for a maximum of three executions. The default value of `maxRetries` is 1. Nextflow tracks which execution a task is on through the built-in variable `task.attempt`. On the first execution, `task.attempt` is 1. On the first retry it becomes 2, on the second retry it becomes 3, and so on. This variable is the key to the most useful pattern in this guide, because you can use it inside other directives to give each attempt more time, more memory, or more CPUs than the one before it. There is a workflow-level counterpart called `maxErrors`, which defines how many tasks in the run may fail before Nextflow stops launching new work. It matters when many independent samples are processed in parallel and you expect a few of them to fail for reasons that a retry cannot fix, such as a corrupt input file. One distinction trips up many people. `maxRetries` controls how many times a *single task* may rerun. `maxErrors` controls how many *distinct tasks* may fail before the pipeline stops. Both belong in your bioinformatics troubleshooting toolkit, but they solve different problems. ## Why bioinformatics pipelines fail transiently Before wiring retries in, it helps to know what kind of failures retries can actually fix. Modern Nextflow pipelines are large, containerized, multi-tool systems. MuSA, an nf-core-compliant Nextflow pipeline for clinical variant annotation, integrates dozens of curated plugins and annotation resources across parallel containerized branches [2]. DNAharvester switches adaptively between BWA-aln, BWA-mem, and Bowtie2 depending on sample preservation [3]. dbcan-nf offers four different analytical routes with very different computational costs [4]. Every extra tool, container, and scheduler interaction is another place where a transient fault can strike. The most common transient failures are: - **Out-of-memory kills.** The scheduler or the operating system kills the process because it exceeded its allocated memory. On Linux this usually surfaces as exit status 137 (SIGKILL) or sometimes 139 (SIGSEGV). - **Walltime exhaustion.** The job hits its time limit. Exit status 124 is typical when a timeout wrapper is involved. - **Node preemption or reboots.** On clusters with preemptible or spot instances, or during scheduled maintenance, running jobs get killed mid-flight. - **Storage and network blips.** A shared filesystem briefly unresponsive, a staged input that timed out during transfer, a container registry that refused one pull out of two hundred. - **Tool-specific flakiness.** A rare segfault in a multithreaded aligner, or a download mirror that failed once. Retries are effective for exactly this class of failure, because rerunning the identical task on a fresh node with fresh memory often succeeds. Retries are useless against deterministic failures, a point covered later under common mistakes. [RNA sequencing](/blog/guides/rna-sequencing) workflows deserve a specific mention here. Splice-aware aligners such as STAR, which underpins clinical splicing-analysis pipelines like SAMI [5], build large in-memory genome indexes. A [human genome](/blog/guides/human-genome) index for STAR demands on the order of tens of gigabytes of RAM, so an RNA-seq error that shows up as exit status 137 is very often a memory allocation problem rather than a data problem. Long-read RNA-seq pipelines such as NextLongIso chain multiple specialized tools across PacBio and ONT data [6], which multiplies the number of task types that can each fail in their own way. When a retry with more memory fixes the task, you want the pipeline to keep going instead of dying, and that is precisely what `errorStrategy 'retry'` with escalating resources buys you. ## Step-by-Step Guide The walkthrough below builds up from a minimal flaky task to a production-grade retry configuration. Create a fresh directory and follow along. ### Step 1. Create a deliberately failing process Make a directory and two files: ```bash mkdir nf-retry-demo && cd nf-retry-demo touch sample.fq.gz ``` Create a file named `main.nf` with this content: ```groovy process FLAKY_ALIGNER { errorStrategy 'retry' maxRetries 2 input: path reads output: path "aligned.sam" script: """ if [ ${task.attempt} -lt 3 ] then echo "Simulated failure on attempt ${task.attempt}" exit 1 fi echo "Succeeded on attempt ${task.attempt}" > aligned.sam """ } workflow { FLAKY_ALIGNER(channel.fromPath('sample.fq.gz')) } ``` The script fails with exit status 1 on attempts 1 and 2 and succeeds on attempt 3. With `errorStrategy 'retry'` and `maxRetries 2`, Nextflow has exactly enough retries to get through. ### Step 2. Run the workflow and watch the retries ```bash nextflow run main.nf -ansi-log false ``` The `-ansi-log false` flag prints plain sequential log lines instead of the animated terminal display, which makes retry behavior visible in CI logs and in pasted terminal output. You will see output along these lines: ``` N E X T F L O W ~ version 24.xx.x Launching `main.nf` [elegant_einstein] DSL2 - revision: (none) executor > local (3) [e7/8c2b10] FLAKY_ALIGNER (1) | 1/1 | FAILED (1) [e7/8c2b10] FLAKY_ALIGNER (1) | 1/1 | RETRY (attempt 2) | FAILED (1) [e7/8c2b10] FLAKY_ALIGNER (1) | 1/1 | RETRY (attempt 3) | OK ``` The exact progress-line formatting varies between Nextflow versions, so treat this as representative rather than byte-for-byte. What does not vary is the underlying behavior: the task hash stays the same, the attempt counter increments, and the run finishes successfully. In the work directory, Nextflow reuses the same task folder across attempts and the `.command.err` and `.command.out` files reflect the most recent attempt. The final summary confirms success: ``` Completed at: (timestamp) Status : SUCCESS Duration : (a few seconds) ``` Had `errorStrategy` been left at its default of `terminate`, the first failure would have aborted the entire run. ### Step 3. Scale resources on every attempt ![Four step flow of a task's cpus, memory and time limit rising on each retry attempt until retries run out.](/article-images/illustrations/nextflow-errorstrategy-maxretries-retry-escalation.webp) The single most valuable pattern in production use is giving each attempt more resources. A task killed for exceeding memory on attempt 1 is likely to succeed on attempt 2 if attempt 2 runs with double the memory. Update the process header: ```groovy process FLAKY_ALIGNER { errorStrategy 'retry' maxRetries 2 cpus { 4 * task.attempt } memory { 8.GB * task.attempt } time { 2.h * task.attempt } input: path reads output: path "aligned.sam" script: """ echo "Attempt ${task.attempt}: ${task.cpus} cpus, ${task.memory}" > aligned.sam """ } ``` Notice that the resource directives are closures, written with braces. Nextflow evaluates them separately for each attempt. The schedule looks like this: | Attempt | CPUs | Memory | Time limit | |--|--|--|--| | 1 | 4 | 8 GB | 2 h | | 2 | 8 | 16 GB | 4 h | | 3 | 12 | 24 GB | 6 h | On a scheduler-based executor, this means each retry is submitted as a new job with the escalated requests, which is what fixes walltime and out-of-memory failures automatically. ### Step 4. Move retry policy into nextflow.config Hard-coding retry behavior in the process definition works, but production pipelines keep it in `nextflow.config` so it can be tuned per compute environment. Create `nextflow.config`: ```groovy process { withLabel:process_medium { cpus = { 8 * task.attempt } memory = { 16.GB * task.attempt } time = { 4.h * task.attempt } errorStrategy = 'retry' maxRetries = 2 } } ``` The `withLabel:` scope applies these settings to every process carrying the `process_medium` label. This is the structure that the nf-core template uses. nf-core is the community framework that a growing share of published Nextflow pipelines follow, including clinical annotation pipelines like MuSA [2], single-cell amplified genome pipelines like CoSAG-nf, which is explicitly implemented to nf-core framework standards [7], and network medicine pipelines integrated into the nf-core project [8]. Learning the label-based configuration pattern means you can read and adjust the retry policy of most nf-core pipelines by editing a handful of lines in one config file. ### Step 5. Retry only the failures that deserve it Blindly retrying every failure wastes cluster time on deterministic errors. Exit codes give you the signal. Exit status 137 almost always means the process was killed, commonly by the out-of-memory manager. Exit status 143 means SIGTERM, often a walltime kill. Exit status 1 usually means the script itself failed in a deterministic way, such as a malformed input file. You can make `errorStrategy` a closure that inspects `task.exitStatus`: ```groovy process { withLabel:process_medium { errorStrategy = { task.exitStatus in 137..140 ? 'retry' : 'terminate' } maxRetries = 2 memory = { 16.GB * task.attempt } } } ``` Here, exit statuses 137 through 140, which cover SIGKILL and related scheduler kills, trigger a retry. Anything else terminates the run immediately so you can fix the real problem. Swap the range for a broader list if your site documents additional transient codes, for example 124 for timeouts and 139 for segmentation faults that you have verified are flaky rather than deterministic for your tool versions. ### Step 6. Use the retry block for per-attempt overrides When you need to change more than scalar resources on a retry, for example swapping a flag on the tool command line, use the `retry` block: ```groovy process TRIMMER { errorStrategy 'retry' maxRetries 1 retry { cpus 8 memory 32.GB ext.args = '--extra-flag' // remove this comment-style prefix if adapting } ... } ``` In practice, the `retry` block redefines any directive for attempts after the first. Directives outside the block apply to all attempts. Keep in mind that `ext.args` values are ordinary Groovy strings, so a real value would be a quoted flag string rather than a comment. The main use is simple: modest resources on attempt 1, generous resources on attempt 2. ### Step 7. Diagnose a task that exhausted its retries Change `maxRetries` to 1 in the demo and rerun. The task now fails on attempts 1 and 2 with no attempt 3 allowed, and the run aborts. In `.nextflow.log` you will find lines of this shape: ``` Task 'FLAKY_ALIGNER (1)' terminated with an error exit status (1) Task error caused retries exhaustion: Task 'FLAKY_ALIGNER (1)' retried 1 time but failed ``` Wording varies slightly between versions, so search for the concepts rather than an exact string: ```bash grep -i "retries" .nextflow.log grep -i "error exit status" .nextflow.log ``` To inspect what actually happened inside the task, find its work directory from the log or from the task hash, then read the standard files Nextflow writes there: ```bash cd work/e7/8c2b10abcdef.../ cat .command.sh # the exact script that ran cat .command.err # stderr from the last attempt cat .command.out # stdout from the last attempt cat .exitcode # the exit status Nextflow observed ``` This inspection step is the core of bioinformatics troubleshooting at the task level. The distinction between task-level debugging and pipeline-level debugging matters, and the software engineering literature on reproducible pipeline development emphasizes systematic validation checks of environment, inputs, and runtime as the way to catch problems early rather than chasing them from stack traces [9]. Reading `.command.err` from the final attempt tells you whether the failure was the same on every attempt (deterministic) or different each time (transient). ### Step 8. Resume a run after fixing the root cause When retries were exhausted and the run aborted, fix the problem, then resume: ```bash nextflow run main.nf -ansi-log false -resume ``` Nextflow re-executes only the tasks that did not complete successfully and serves everything else from its cache. Resume behavior is a first-class feature in real pipelines, and published workflows cite it explicitly: dcHiChIP advertises batch processing and workflow resumability as core capabilities [10], and FORGE describes itself as robust to interruption and optimized for cluster-based compute environments [11]. On a laptop demo, resuming after a deliberate failure costs seconds. On a large cohort, it is the difference between rerunning hours or days of finished work and rerunning one task. Retries and resume compose cleanly. A task that succeeded on attempt 3 is a completed task, and a later `-resume` run treats it as cached and does not touch it. ### Step 9. Tolerate a few bad samples with maxErrors When you process many independent samples, one doomed input should not necessarily kill the run. Set `maxErrors` in `nextflow.config`: ```groovy maxErrors = 3 ``` Now up to three tasks can fail before Nextflow stops launching new work. Successful tasks continue and their results are kept. Combine this with per-process `errorStrategy 'retry'` so transient failures self-heal while genuinely broken samples fail fast and get reported. At the end of the run, Nextflow lists the failed tasks, and a `-resume` run after you repair the bad inputs processes only those samples. A concrete sense of why this matters at scale. The gVCF2CNV pipeline converted gVCF files for 12,509 individuals, completing signal extraction in 4 hours on 192 CPUs, and then processed 414,824 individuals from the All of Us cohort in 96 hours [12]. The NEXT-scASV pipeline processed allele-specific variant calling for 135,000 single cells from 57 donors over about a week on a single node with 100 threads [13]. At these scales, even a one-in-a-thousand transient failure rate guarantees several failures per run. Retry policies and bounded error tolerance are not optional at cohort scale, they are how the run finishes. ## Key options at a glance | Directive or variable | Where it applies | What it does | Typical value | |--|--|--|--| | `errorStrategy 'terminate'` | Process | Default. Stops the run on task failure. | Leave as fallback for deterministic failures | | `errorStrategy 'retry'` | Process | Re-executes the failed task. | Pair with `maxRetries` | | `errorStrategy 'ignore'` | Process | Logs the failure and continues. | Optional, non-critical steps only | | `errorStrategy { closure }` | Process | Chooses the strategy per failure, can read `task.exitStatus`. | Retry kill codes, terminate on code 1 | | `maxRetries N` | Process | Maximum number of retries per task. Default 1. | 1 to 3 | | `maxErrors N` | Config (workflow level) | Number of distinct failed tasks tolerated before stopping. | Small integer | | `task.attempt` | Inside process closures | Current attempt number, starting at 1. | Multiplier for `cpus`, `memory`, `time` | | `retry { ... }` block | Process body | Redefines directives for attempts after the first. | Bumped memory and time | ## Patterns for production pipelines ### The exit-code whitelist ![Decision path that reads a task exit status and chooses between retrying, adding the code to the whitelist, or stopping the run.](/article-images/illustrations/nextflow-errorstrategy-maxretries-exit-code-triage.webp) The pattern from Step 5 generalizes into a whitelist of scheduler-related kill codes, with `terminate` as the default for everything else. This gives you the best of both worlds: transient infrastructure failures self-heal, while real bugs stop the run immediately with a clean stack trace. If you use community pipelines, this logic is already written for you in their configs, and it is worth reading those files before writing your own. ### Containerized execution and retries Retry success often depends on the retry running in a clean environment. Containerized pipelines make that automatic, because each task execution starts a fresh container. Streamline CNV, for example, is distributed as a Docker image that can be executed using Singularity so that the same task reruns identically across different user environments [1]. PerSeqPIPE similarly supports reproducible execution through Docker and Apptainer [14]. If your retry keeps failing with the same error inside a container, suspect the image or the reference data baked into it, not the scheduler. ### Validating inputs before the expensive steps The cheapest retry is the one that never has to happen. Workflows that pre-check their environment, inputs, and runtime conditions fail fast with clear messages instead of burning an hour of compute on a doomed task [9]. In practice this means a small first process that verifies file sizes, checksums, and reference index presence before the memory-heavy steps run. It also means testing your retry logic itself with synthetic data inside continuous integration rather than discovering during a production run that your retry block contains a typo. Community pipelines with modular, well-defined task interfaces make these checks reusable [9]. ## Verifying that retries worked Do not trust the happy final summary alone. Three checks confirm that retry behavior is active and correctly scoped. **Check 1. The trace file.** Run with `-with-trace`: ```bash nextflow run main.nf -ansi-log false -with-trace trace.txt ``` The `trace.txt` file records one row per task execution, including failed attempts, with columns for status, attempt number, duration, exit status, and resource metrics. A task that succeeded on its third execution shows its final attempt number, and failed attempts appear as their own rows. This is the cleanest programmatic record for auditing how many times each task in a cohort-scale run needed. **Check 2. The run log.** ```bash nextflow log nextflow log -f process,status,exit ``` The first command lists every run in the directory with its status. The second prints the per-task process name, final status, and exit code from the most recent run, which lets you confirm that your retried tasks ended with status `COMPLETED` and exit code 0. **Check 3. The work directory.** For any task of interest, the `.exitcode` file holds the exit status of the most recent attempt, and `.command.err` holds its stderr. If `.command.err` ends with the same error on every attempt, your retry policy is running but the failure is deterministic, which points back at inputs, versions, or configuration rather than infrastructure. ## Reading the exact error messages A few messages you are likely to meet during bioinformatics troubleshooting, with what each one means and the fix. - **"terminated with an error exit status (137)"**. The task was killed by SIGKILL, in practice almost always the out-of-memory killer or the scheduler enforcing a memory limit. Fix by raising `memory` for that labeled process, or rely on the escalating `memory { X.GB * task.attempt }` pattern so the retry outruns the kill. - **"terminated with an error exit status (124)"**. The task hit a timeout. Raise `time`, again ideally per attempt. - **"terminated with an error exit status (139)"**. SIGSEGV. Sometimes a genuine transient segfault in a threaded tool, which a retry fixes. If every attempt segfaults, suspect an incompatible binary or corrupted input, not the scheduler. - **"Task error caused retries exhaustion"**. The task used all attempts allowed by `maxRetries` and still failed. Read `.command.err` in the work directory to decide whether the failure is transient (raise `maxRetries` or escalate resources further) or deterministic (fix the cause, then `-resume`). - **"Command error ... command not found"**. The tool binary was not on the path inside the task. Retry will never fix this. Fix the container image or module load configuration. - **Repeated submission failures from the executor**. When the scheduler rejects job submissions, for example because a partition is full or the requested resources exceed partition limits, retries do not help because the task never ran. Check scheduler limits, queue names, and account settings. ## Common Mistakes and Limitations **Mistake 1. Applying `ignore` to a core analysis step.** `errorStrategy 'ignore'` lets the run continue as if the task had succeeded, which means downstream tasks may run with missing or empty inputs and quietly produce garbage results. Reserve `ignore` for genuinely optional steps such as optional report generation, and even then check outputs afterward. **Mistake 2. Retrying deterministic failures forever.** A malformed FASTQ, a reference index built with the wrong genome release, or a container with a broken binary fails identically on every attempt. Retry with generous resources is the right tool for transient infrastructure faults, not for bugs. Use the exit-code whitelist so that only kill-class codes trigger retries. **Mistake 3. Setting `maxRetries` too high.** Each retry re-runs the full task from scratch. A task that takes 12 hours and fails at hour 11 costs another 12 hours per retry. Two or three retries is a sensible ceiling for most pipelines. More than that usually hides an unaddressed root cause and multiplies cluster cost. **Mistake 4. Forgetting that retries restart the whole task.** Nextflow does not checkpoint inside your script. A partially written BAM is discarded and the aligner runs again from the beginning. For very long tasks, consider splitting the work so each retry is cheaper. **Mistake 5. Confusing `maxRetries` with `maxErrors`.** One limits attempts per task, the other limits failed tasks per run. Setting only `maxErrors` without `errorStrategy 'retry'` gives you no self-healing at all, just permission to lose samples silently. **Mistake 6. Escalating resources without checking scheduler limits.** The `memory { 8.GB * task.attempt }` pattern is only useful if the third attempt's request can actually be satisfied by the queue. If your partition caps jobs at 64 GB, an attempt requesting 128 GB will fail to submit, which looks like a mysterious pipeline failure. Match escalation ceilings to your real partition limits. **Mistake 7. Mixing shell variables with Groovy interpolation incorrectly.** In a process script block, `${task.attempt}` is interpolated by Groovy. A shell variable must be escaped as `\${variable}` or the Groovy engine will try to resolve it and either error out or substitute nothing. This produces some of the most confusing syntax errors beginners hit, and it is worth memorizing early. **Mistake 8. Testing retry logic only in production.** The demo process in this guide is deliberately trivial so you can exercise retries safely. Run your own flaky-task simulations before a large cohort run. Software engineering guidance for bioinformatics pipelines stresses testing with both real and synthetic data within continuous integration workflows precisely so that failure behavior, including retry behavior, is verified before it matters [9]. One honest limitation of `errorStrategy 'retry'` overall: it addresses execution failures, not scientific validity. A pipeline can retry successfully all the way to completion and still produce a biologically wrong result if the reference genome, annotation version, or sample sheet is wrong. Reliability engineering and analytical correctness are separate responsibilities, and the former must never be used as evidence for the latter. ## Frequently Asked Questions ### What is the default errorStrategy in Nextflow? The default is `terminate`, meaning the first task failure stops the entire run. You must opt in to `retry` or `ignore` per process or through a `withLabel` scope in your configuration. ### What is the default value of maxRetries? The default is 1, so with `errorStrategy 'retry'` and no explicit `maxRetries`, a failing task gets exactly one retry. Set `maxRetries 2` or `3` for infrastructure-heavy environments with frequent node preemption. ### Can I set retry behavior globally for all processes? Yes. In `nextflow.config`, set `errorStrategy = 'retry'` and `maxRetries = 2` inside the top-level `process { }` scope, then override specific processes with `withLabel:` or `withName:` blocks where different behavior is needed. ### How do retries interact with the -resume option? Completed tasks are cached and skipped on a resumed run, and a task that succeeded on its second or third attempt counts as completed. Tasks that failed are re-executed from attempt 1 on the resumed run, so fixing the root cause and resuming processes only the broken tasks. ### Does a retry rerun the task from scratch? Yes. Nextflow re-executes the entire process script in the task work directory with no intermediate checkpointing, and the `.command.err` and `.command.out` files after a run reflect the most recent attempt. ### When should I use errorStrategy ignore instead of retry? Almost never for analysis steps. Use `ignore` only for optional, non-critical tasks such as supplementary report generation where a missing output is acceptable and detectable, and always verify outputs downstream afterward. ### How do I give a retry more memory than the first attempt? Make the memory directive a closure that multiplies by `task.attempt`, for example `memory { 16.GB * task.attempt }`, or define larger values inside a `retry { }` block. Both are evaluated per attempt by Nextflow. ### Why does my retried task keep failing? Because the failure is deterministic, not transient. Read `.command.err` in the task work directory. If every attempt shows the identical error, fix the input file, container image, reference index, or configuration, then resume the run. Retries only repair failures that vary between executions. ## Sources 1. [Streamline CNV - A Handy Nextflow Pipeline for Chromosomal Copy Number Variation Analysis.](https://pubmed.ncbi.nlm.nih.gov/42995894/) 2. [MuSA: a Nextflow pipeline for deep, reproducible annotation and clinical ranking of genomic variants.](https://pubmed.ncbi.nlm.nih.gov/42304195/) 3. [DNAharvester: a nextflow pipeline for analysing highly degraded DNA from ancient and historical specimens.](https://pubmed.ncbi.nlm.nih.gov/42886518/) 4. [dbcan-nf: a Nextflow pipeline for accurate CAZyme annotation in metagenomes.](https://pubmed.ncbi.nlm.nih.gov/42899262/) 5. [Detecting unannotated splicing events in short-read RNA-seq with SAMI, a UMI-aware Nextflow pipeline.](https://pubmed.ncbi.nlm.nih.gov/42166739/) 6. [NextLongIso: a comprehensive Nextflow pipeline for multi-dimensional long-read RNA-seq analysis.](https://pubmed.ncbi.nlm.nih.gov/42544764/) 7. [CoSAG-nf: a scalable nextflow pipeline for co-assembly, optimization, and interactive visualization of high-throughput single-cell genomes.](https://pubmed.ncbi.nlm.nih.gov/42752543/) 8. [Inferring and evaluating network medicine-based disease modules with nextflow.](https://pubmed.ncbi.nlm.nih.gov/42412786/) 9. [Software engineering for reproducible pipeline development in bioinformatics.](https://pubmed.ncbi.nlm.nih.gov/42756310/) 10. [dcHiChIP: a comprehensive Nextflow-based pipeline for multiscale analysis of chromatin architecture from HiChIP data.](https://pubmed.ncbi.nlm.nih.gov/42730630/) 11. [Flow Orchestrated Regulatory Genomics Engine (FORGE): A Configurable Nextflow Pipeline for End-to-End snMultiome Analysis.](https://pubmed.ncbi.nlm.nih.gov/42780179/) 12. [gVCF2CNV: a scalable pipeline for CNV detection from whole-genome sequencing data.](https://pubmed.ncbi.nlm.nih.gov/42922522/) 13. [NEXT-scASV: a Nextflow pipeline for allele-specific variant calling from single-cell RNA-seq data.](https://pubmed.ncbi.nlm.nih.gov/41947412/) 14. [PerSeqPIPE: Nextflow workflow for per-sequence analysis of small RNA-sequencing data.](https://pubmed.ncbi.nlm.nih.gov/42893276/)