Updates

A run is waiting on your confirmation in Spacelift. You're heads down in Slack or Microsoft Teams. You find out when someone asks why the deploy stalled.

Your day runs through Slack, Teams, and GitHub, not a Spacelift tab. Now your notifications can follow you there.

Link your Slack, Microsoft Teams, and GitHub accounts to your Spacelift identity from Personal Settings > External Accounts. Once you authorize the connection, notification policies can reference your linked account directly. A policy can mention the commit author when their tracked run fails, or ping whoever triggered a run the moment it needs their attention.

That also retires the hardcoded user map. Getting a mention right used to mean keeping a table like "bob": "U08MA4D50RY" inside your policy and updating it every time someone joined or left. Now the policy reads the linked ID straight from the input:

rego

author_identity.federations["slack-oauth"].id creator_session.identity.federations["slack-oauth"].id

If someone hasn't linked an account, the rule doesn't fire, so nobody gets a mention meant for someone else.

This feature is available on all plans and ready for you to take for spin, and tell us what you think! We love to hear from you.

Read the notification policy docs →

An unconfirmed run doesn't just disappear from existence. It sits there in Spacelift, waiting on a response, until someone remembers to deal with it. These can stack up and leave your run list pretty crowded. We just introduced a quality of life improvement for you.

Starting today, any run that doesn't reach a final state within 30 days of creation will expire and be removed from the queue, including runs that are simply waiting for approval or confirmation. Be sure to check the Runs to be Terminated widget on your Dashboard to see which runs will be expired within the next 7 days:

Finished runs and your existing infrastructure will not be affected in any way. If there's a run you still need, make sure it is approved, confirmed, or finished in some way before it hits the 30 day mark.

We love when we can deliver features that many of you have specifically asked for. And today is yet another one of those days. Runs on private worker pools now have three priority levels instead of two. You could always push a run priority up, to make sure it is processed first. Now you can push it down, so it waits behind everything at normal or higher levels.

• UI: Set priority from a run's page, the flag icon in a worker pool's queue, or the three-dot menu. The queue filters and sorts by priority, and bulk actions set the level on multiple runs at once.

• CLI: spacectl stack priority <low|normal|high> (spacectl 1.26.0+)

• API: Set it with the runPrioritySet mutation, read it with priorityPreset on Run.

• Push policies: Return priority (high, normal, or low) to set a run's starting level. The existing boolean prioritize rule still works and maps to high.

Low-priority runs still queue ahead of drift detection. This feature is available on private worker pools only. As always, take it for a spin, and tell us what you think!

Run prioritization docs · Push policy prioritization docs