Skip to main content

Default branch health and merge guardrails

Feature Requests

We are using Spacelift’s merge then apply model, where plans run on PRs and then a tracked run applies on the default branch after merge. Our main concern is what happens when that apply on main fails. At that point the default branch is effectively broken, but other teams can still merge on top of it, which is risky for us as a crypto exchange.

We would like Spacelift to have a clear concept of “default branch health” per stack, for example: healthy, waiting for confirmation, or failing. That state should be visible in the Spacelift UI and, ideally, exposed back to GitHub as a status check or automated comment on open PRs. We’d like a “warn only” mode, where merges are still allowed but clearly flagged, and a stricter mode where a required check blocks merges while the default branch is failing, with a controlled bypass for a designated “fix” PR or specific roles.

Right now we can approximate this with custom policies and external automation, but it adds a lot of complexity. Having branch health and merge guardrails as a native feature would make the recommended merge then apply flow safer and simpler for teams like ours.

Status: ⬆️ Gathering votes5 comments

Log in to comment and vote

Comments5

  • Coffee Robin

    Team•

    Dec 18, 2025

    •

    Merged request

    •

    1 vote

    Branch health guardrail surfaced as a PR check for all stacks

    Today it is too easy for teams to keep building on top of a broken tracked branch without realizing it.
    Concrete issues

    • A proposed run on a PR can pass, the PR gets merged, but the tracked run on the default branch fails only at apply time. So from the developer perspective the change looked safe.

    • The main signal that something is wrong lives in Spacelift UI and Slack notifications. Developers often ignore Slack because it is already noisy and outside their normal dev workflow.

    • Locking stacks is not a good fit here. It can block teams when the person who caused the issue is offline, and it adds more friction and social overhead instead of clarity.

    As a result

    • Developers keep opening and merging PRs on top of an unhealthy tracked branch.

    • Platform teams spend time chasing people and explaining why their “green” PR actually introduced a problem.

    • This increases cognitive load.

    I want to see a clear signal in my PR when the tracked branch for that stack is unhealthy
    so that I know it is not safe to merge and I can coordinate fixing main first.
    As a platform engineer I want branch health to be enforced as a PR check, not just a Slack notification
    so that I do not have to rely on people watching Slack or learning Spacelift UI to avoid breaking workflows.
    Desired behavior

    1. Branch health state per stack

    • Spacelift maintains a simple health state for each stack’s tracked branch, for example healthy or unhealthy.

    • This state reflects the status of the latest tracked runs on the tracked branch, including failed applies that passed plan.

    1. PR health check on every proposed run

    • For every proposed run triggered by a PR that touches a given stack, Spacelift evaluates the stack’s branch health.

    • If the tracked branch is unhealthy, Spacelift

    • fails a dedicated “Branch health” check in the VCS

    • optionally posts a comment on the PR explaining that main is unhealthy, with a link to the failing tracked run and its logs.

    1. Scope

    • The health check applies to all future PRs affecting that stack from the moment the tracked branch becomes unhealthy.

    • It is not limited to the original PR that introduced the problem. Anyone trying to build on top of a broken main gets the same warning.

  • Black Breeze

    •

    Nov 14, 2025

    I think I know what you’re after… Just thinking out loud - if we exposed the “stack health” (was the tracked last run green?) in the body of an approval policy input, would that be enough to let you make a decision on how to proceed?