Skip to main content

Stack Run View should display place in queue

Feature Requests

A Run will display worker count and pending runs, but not the current place in queue. This should be visible from the Run view.

There should also be a way to see how many queued Runs have been marked Priority. This could help inform if the open Run should be marked as Priority.

Status: 🗑️ Archived3 comments

Log in to comment and vote

Comments3

  • Natalia Gazda

    Team•

    Jul 16

    Hey, thanks for the suggestion. We're archiving this one for now. It hasn't picked up much interest since it went up, so it isn't on our near-term roadmap. Archiving isn't deleting: the request stays on record, and if it gathers more votes or comments we can bring it back. If it still matters to you, add a vote or a comment so we can gauge the demand.

  • Rose Beaver

    •

    Jun 18, 2025

    Hi Marcin,
    not the original poster, but I’d like to add our view on the necessity of having this simple feature added. It would of course not solve the contention on workers, but at least give the minimum required visibility for simple users of the platform (it seems only Admins can view the Worker Pools page, although I couldn’t find any docs confirming this).

    It is a very common occurrence that someone in our Platform Engineering team triggers a single change that then gets applied to various environment and regions over 10-20 stack runs. We have several other users of our internal platform that infrequently interact with Spacelift runs. They look at their Proposed Run to check out the plan and see that it’s queueing for a while, but don’t know why and even after we tell them it’s just queued behind other stacks, they don’t know when they should be checking back. To be clear, we’re ok with having to wait for these stacks to run, but not being able to see for a queued stack why it’s not starting to run just leads to unnecessary and totally avoidable communication overhead.

    We have explored adding more “concurrency” (i.e. additional public pool workers), but to solve this problem we would need to go from concurrency 2 to something like concurrency 10 and that’s just not gonna fly with Spacelift’s current concurrency-unfriendly pricing model. That would only make sense to us if Spacelift would offer something like runtime-base pricing like other CI platforms instead of upfront payable 24/7 workers.

  • Black Breeze

    •

    May 10, 2025

    Thanks for the suggestion! We’ve heard similar requests before, so wanted to step back and understand the job you’re trying to do. It sounds like you’re running into queue contention and trying to manually prioritize runs by hand — essentially acting as the human scheduler.

    We totally get the frustration, but we’d gently suggest that visibility into queue position might not solve the real problem. If you’re hitting frequent queuing delays, it likely means:

    1. You have more infrastructure change happening than your current worker capacity can handle.

    2. You’re spending valuable time manually routing jobs rather than letting the system flow.

    We’d love to understand more: what decisions would you make differently if you could see queue position? And how often do those decisions materially improve throughput?

    Sometimes the better fix is increasing concurrency (p95 billing helps), or reducing unnecessary runs. We’re happy to explore both paths with you — and if queue visibility is still useful after that, let’s talk.