Skip to main content

First class notifications to commit / merge author for confirm and failed tracked runs

Feature Requests

To make merge then apply safe in practice, we need the right person to be notified at the right time. Today, when a tracked run on the default branch is waiting for confirmation, or when it fails, it is too easy for the original author to miss it. This is especially painful when an apply fails on main and quietly leaves the branch in a bad state.

We would like a built-in way to configure, per stack or per space, that Spacelift automatically notifies the commit or merge author whenever: (a) a tracked run on the default branch is waiting for confirmation, and (b) a tracked run on the default branch fails. The key channel for us is Slack, ideally with a direct mention in a team channel, with email as a nice-to-have.

We can build this ourselves with notification policies, Rego and external glue against your APIs and GitHub, but that increases our maintenance burden. Having “notify commit/merge author on confirm/fail” as a first class option would solve a very common operational problem without requiring each customer to reinvent it.

Status: ⬆️ Gathering votes3 comments

Log in to comment and vote

Comments3

  • Ovidiu Moise

    Team•

    Aug 7

    hey @Muriel Picone . FYI, we recently released the ability for users to connect their Slack/Github/(soon) Teams to their Spacelift user. Once that happens, you can start sending native Slack notifications, according to this documentation, using notification policies: https://docs.spacelift.io/concepts/policy/notification-policy.html#notifying-the-commit-author

    Docs on linking Slack: https://docs.spacelift.io/concepts/identity-access-management/external-accounts.html

  • Black Breeze

    •

    Nov 14, 2025

    Hi there,

    Thanks for the detailed feature request! We appreciate you taking the time to explain the use case around making merge-then-apply workflows safer.

    To help us better understand the exact flow you're envisioning, could you clarify a few things?

    Author Identification:
    • How should Spacelift identify the "commit/merge author" to notify? For example:
    • Should we use the Git commit author from the commit history?
    • For merge commits, should we notify the person who merged the PR, or the author(s) of the commits in that PR?
    • If a tracked run includes multiple commits from different authors, who should be notified?

    User Mapping:
    • How should we map Git authors to notification recipients? For example:
    • For Slack: Should we match Git email addresses to Slack users in your workspace? Or would you configure a mapping somewhere?
    • For email: Should we simply use the Git commit author email, or would you want a different mapping?

    Notification Content:
    • What specific information would you want included in these notifications? (e.g., stack name, run ID, commit SHA, failure reason, link to confirm, etc.)Configuration:
    • You mentioned configuring this "per stack or per space" - would you want this to be opt-in or opt-out? Any specific configuration options you'd need beyond enabling/disabling it?

    I’d love to understand these details before we can start thinking about a solution. Thanks again!

    • Red Glacier

      •

      Nov 14, 2025

      Thank you for following up so quickly on this :)
      I’ll address the points one by one:

      Author Identification: ideally, for us it would notify all the people involved. This way, the chances of somebody taking action promptly increase.

      User Mapping:
      - For email, yes, using the git commit author email makes sense
      - For Slack, matching Git email addresses to the Slack users would be ideal.

      Notification Content:
      Stack name, commit SHA with link, and link to confirm/see the logs would be good.
      And yes, enabling/disabling should be enough for our use case.

      Let me know if there’s anything else I can help with