Skip to main content

Support different stacks priority levels

Feature RequestsStacksWorkers

Right now, priority is binary, a Stack is either a priority or not, for its worker pool. Would be great to have the means to define a priority order, a rank, e.g., from 1 to 5 or from Low to Very High.

Workaround
No
Problem
Status: ❌ Rejected3 comments

Log in to comment and vote

Comments3

  • Coffee Robin

    Team•

    Mar 17

    •

    Merged request

    •

    1 vote

    Automatic Stack Priority Configuration

    We only have a small number of workers, and sometimes pull request runs occupy the worker pool while we are trying to deploy production changes.

    It would be helpful if we could configure certain stacks, such as production stacks, to always have higher priority automatically.

    Currently, we can manually prioritize runs, but an automatic or multi-level priority system would make this more reliable and reduce operational friction.

    • Black Breeze

      •

      Mar 17

      Thanks for the suggestion! We hear you on the frustration of juggling run priorities manually - it's not a great experience.

      That said, we're a bit wary of building deeper priority routing for this case. In practice, fine-grained priority configuration tends to create its own operational burden: you end up needing to categorize every stack, debug why something didn't run when expected, and tune settings as your infrastructure grows. We've seen this pattern with drift detection (where we already allow capping workers), and even simple knobs can become a source of confusion over time.

      The more reliable path here is dedicated capacity - a small number of workers reserved for production means you never have to think about priority at all. It's less configuration, not more.

      We're going to pass on this one for now, but appreciate you sharing the use case!

  • Black Breeze

    •

    Jun 6, 2025

    This was our initial design actually, but we analyzed pros and cons and decided that it would be overcomplicating the product without a clear, substantial gain. We are planning two improvements to worker pool utilization, specifically focusing on drift detection runs. Hopefully these make the need for such granular prioritization less pronounced.