Welcome @kiersten-scott – I think we can help!
Yes, purging the running dataset will usually work to kill an unwanted job. How this technically works as a user in the web application is that the next time the job needs to interact with the rest of the job running parts of the database (an input, or the history), a connection will “go wrong”, then the job fails. But this means letting the job process on the cluster node first.. unless it is still queued, then it will die before getting the final dispatch message.
Since this is your own Galaxy, you could kill the job wherever it is running, then clean up the database. This topic has what worked for another person (who didn’t have gxadmin set up due to the default database still be used). → How to kill a failed job without gxadmin?
The gxadmin command do all of this for you. This is a reply from the author.
Other than that, if you have the cluster resources available to run more jobs, I am wondering if you need to adjust how many concurrent processes are allowed. This is adjustable on the server and per user and we can share where to set these. The version of Galaxy and which database you are using might matter, so please include those.
Thanks and let us know! 