# Job still running for more than 15 hours **URL:** \ **Category:** usegalaxy.eu support\ **Tags:** queued-gray-datasets, exceeds-memory-error\ **Created:** [February 3, 2026, 4:53am UTC](https://help.galaxyproject.org/t/job-still-running-for-more-than-15-hours/17405 "2026-02-03T04:53:18Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![jennaj](https://sea2.discourse-cdn.com/flex020/user_avatar/help.galaxyproject.org/jennaj/32/27_2.png) [@jennaj](https://help.galaxyproject.org/u/jennaj)\ **Post date:** [February 7, 2026, 10:42pm UTC](https://help.galaxyproject.org/t/job-still-running-for-more-than-15-hours/17405/6 "2026-02-07T22:42:26Z")
Hi @Monish_V Thanks for sharing the history! Very helpful. I don’t see anything special about the mapping run here. It seems to have not started the mapping part at all but instead was quit out before the job was finished with queueing, so it didn’t even get assigned to a cluster node yet. Is this the example you meant to share? Do you want to share the history with the errors from a job that failed during processing? Or have you quit out of all prior jobs? The best way to get information for a strange job is to allow it to finish processing. A mapping job could queue for a day or so, and then finally start processing. After 15 hours, it may still be queued (how the job above seems to have been) or it may be just starting the actual mapping job. This doesn’t need to delay you for other analysis. Meaning, you can keep going and start up new work involving other at the same time. That can be in the same history or a different history – either is fine! The server knows how to keep track of tens of thousands of your jobs all at the same time. I’m wondering if explaining how the clusters work would help? The color of a dataset can give some clues about the processing stage work is in. The topic below has some short help about computational resources at the public servers. > [@Troubleshooting resources for errors or unexpected results](https://help.galaxyproject.org/t/troubleshooting-resources-for-errors-or-unexpected-results/42/1): > > ⏰ When working at [UseGalaxy.org](http://UseGalaxy.org), [UseGalaxy.eu](http://UseGalaxy.eu), or [UseGalaxy.org.au](http://UseGalaxy.org.au), your analysis jobs execute [at large scale academic clusters](https://training.galaxyproject.org/training-material/faqs/galaxy/#analysis). Hundreds of thousands of jobs process each month! > > - Use a [Workflow](https://training.galaxyproject.org/training-material/search2?query=workflow) for batch work. > - Allow [queued (grey color) and executing (yellow-orange) datasets](https://training.galaxyproject.org/training-material/faqs/galaxy/datasets_job_status.html) to finish processing. > - Deleting and rerunning puts your job back _at the end_ of the queue again! > - Job priority is the exactly the same for everyone. > - **Be patient**. Galaxy is a free service, when a lot of people are using it, [you may have to wait longer than usual](https://training.galaxyproject.org/training-material/faqs/galaxy/analysis_jobs_not_running.html) (especially for ‘big’ jobs, e.g. alignments). * * * You’ll find many more explanations in topics tagged with #queued-gray-datasets . Some explain how to investigate the server performance, example → [How to see the UseGalaxy.eu job queue statistics](https://help.galaxyproject.org/t/how-to-see-the-usegalaxy-eu-job-queue-statistics/11837) Most public servers work about the same way! The best advice is to get your jobs into the queue then to allow them to completely process. If later on an odd error comes in, include a resource issue, you can share the example and we’ll be able to offer advice. This can include reaching out to cluster administrators to learn if resources can be adjusted, but also helping you to organize your data or parameters a bit differently. As a test, I started up a test history here that I’ll let run over the weekend. It is the same accession you were using. I pulled in the SRR11296739 sample [GSM4408849: MSI-H, likely Lynch due MLH1 germline sample 7 tumor tiss... - SRA - NCBI](https://www.ncbi.nlm.nih.gov/sra/SRR11296739) from NCBI the same way you did to start with. Next, I ran a simple generic QA workflow [Galaxy](https://usegalaxy.eu/u/jenj/w/quality-control-q20-l20) on the raw reads to see what happens. Next, I’ll try to map the reads using **HISAT2** (defaults) against the `hg38` native index. This sample isn’t overly large but as @Gabriel explained it will route to a larger and busier cluster node than you may have experienced before (during a training session, or simply when the server was less busy!). My job will probably have the same automatic rerun invoked unless the additional QA helps the reads to map cleaner. In either case, that’s ok, let’s let it complete until the end. - [https://usegalaxy.eu/u/jenj/h/test-srr11296739-qa-and-mapping](https://usegalaxy.eu/u/jenj/h/test-srr11296739-qa-and-mapping) Hope this helps to keep things going and after the weekend we’ll have some more data to look at. You are still welcome to share back any job that failed on its own (not canceled by you) for a closer look. Thanks! 🙂 --- _[View the full topic](https://help.galaxyproject.org/t/job-still-running-for-more-than-15-hours/17405)._