Skip to main content

Deprioritize Run option

Feature Requests

Jobs are launched at what I’ll call “standard” prioritization. Using the “Flag” icon in the Worker Pool Queue view I can increase the prioritization of runs.

I’d like to specifically be able to de-prioritize runs in the case of large deploys so as not to adversely impact other teams.

Workaround
Problem
See above
Status: ✅ Completed8 comments

Log in to comment and vote

Comments8

  • Jonah Kowall

    Team•

    Jul 12

    Thanks for the idea. Two existing mechanisms cover this job from the opposite direction: Spacelift automatically prioritizes blocking runs over proposed and drift detection runs (https://docs.spacelift.io/concepts/run), and on private worker pools you can reorder the queue to move any run ahead of another: https://docs.spacelift.io/concepts/worker-pools. Worker pools can also be configured to automatically de-prioritize drift detection jobs at capacity. Explicit down-prioritization of a single run hasn’t attracted demand, so I’m closing this as covered. If queue reordering doesn’t work for your case, tell us why and we’ll revisit.

    • Sapphire Geyser

      •

      Aug 18

      For what it’s worth, the two mechanisms you mentioned talk about de-prioritizing drift detection jobs which have nothing to do with my feature request/suggestion.

      So these mechanisms certainly do not “cover” my issue. You can close it due to lack of demand I suppose.

      • Jonah Kowall

        Team•

        Aug 19

        Yes, that’s why the decision was made on this one. It does come up from time to time, and we can always re-open it if demand is there. We try to de-prioritize other runs such as drift detection (and in the future unmanaged resources scans).

        • Sapphire Geyser

          •

          Aug 19

          Ok, just to be 100% clear, this isn’t about drift. This is about large infrastructure deploys which end up triggering 100’s of stacks. When our infra/platform team need to carry these deployments, without manual intervention to PRIORITIZE application/dev team deploys, block ability to deploy platform changes.

          Thank you.

  • Natalia Gazda

    Team•

    Jul 19, 2025

    Hi @Steve Smith, thanks for the additional context. A few questions to better understand your use case:

    • How many concurrent workers do you typically run day-to-day, and what's your peak concurrency during these monthly upgrade windows?

    • Are you familiar with our p95 concurrency pricing model? It allows you to burst above your committed concurrency without penalty - you're only billed based on your 95th percentile usage. This means those monthly spikes might already be covered within your existing pricing structure.

    • Have you considered temporarily scaling up your worker pool during these maintenance windows instead of managing priorities?

    Understanding your concurrency patterns would help us determine if this is something that needs a new feature, or if existing capabilities might already solve your problem.

    • Sapphire Geyser

      •

      Jul 21, 2025

      • We have 6 workers deployed normally deployed.

      • Yes, we’re familiar with that model. We run the 6 that we pay for full time. I think the last time we looked at this we calculated we could run another worker for about 20 minutes per month to not get hit with another worker for the month? Can you help us verify that math? Maybe we calculated it wrong?

  • Natalia Gazda

    Team•

    Jul 15, 2025

    Hi @Steve Smith, thanks for submitting this. I totally understand what you mean, and I wanted to ask fe more things.

    • For what kind of runs does it usually happen? Drift detection? Large deploys?

    • How often does it occur?

    • Sapphire Geyser

      •

      Jul 16, 2025

      • For what kind of runs does it usually happen? Drift detection? Large deploys?

        • This happens mainly when the infra team needs to deploy a large/sweeping change to the environment. An example is a Terraform/OpenTofu upgrade where hundreds of stacks need to run.

      • How often does it occur?

        • This has been occurring about once a month or so for us.