Thanks for the suggestion! This is a thoughtful idea, and we appreciate you taking the time to share it. That said, we currently deprioritize drift detection jobs internally—they already run with the lowest scheduling priority and are designed not to compete with higher-urgency workloads like plan or apply operations.
Given that, dedicating private worker capacity specifically for drift detection isn’t something we’re planning to support. We’d rather keep things simple and avoid adding configuration overhead for jobs that are already non-blocking by design.
If you’re seeing drift detection impact your run queue in a meaningful way, though, please reach out—we’d love to understand more about your setup.
Orange Pond
•
May 27, 2025
That said, we currently deprioritize drift detection jobs internally—they already run with the lowest scheduling priority and are designed not to compete with higher-urgency workloads like plan or apply operations.
This is great to learn! Do you have any documentation of this behavior I can reference?
Log in to comment and vote
Comments2
Black Breeze
May 10, 2025
Thanks for the suggestion! This is a thoughtful idea, and we appreciate you taking the time to share it. That said, we currently deprioritize drift detection jobs internally—they already run with the lowest scheduling priority and are designed not to compete with higher-urgency workloads like plan or apply operations.
Given that, dedicating private worker capacity specifically for drift detection isn’t something we’re planning to support. We’d rather keep things simple and avoid adding configuration overhead for jobs that are already non-blocking by design.
If you’re seeing drift detection impact your run queue in a meaningful way, though, please reach out—we’d love to understand more about your setup.
Orange Pond
May 27, 2025
This is great to learn! Do you have any documentation of this behavior I can reference?