Release tracking

When you ship, the right teams know — automatically.

Route every release to the right Slack channel based on the labels you already put on your GitHub pull requests. Different PRs go to different channels — no copy-paste, no @mentions, no chasing.

Available on the Pro and Enterprise plans.

#support
Pipie
Pipie 03:40
:package: *Release v1.4.2 has been released* Repository: acme/auth-service
Pipie
Pipie 03:40
• <https://github.com/acme/auth-service/pull/142|Auto-suspend free trial after 14 days> Notifies the customer 24h before suspension and auto-cancels the subscription if no card is on file.
Pipie
Pipie 03:41
• <https://github.com/acme/auth-service/pull/144|Add billing-history export> Users can now export their invoices to CSV from the billing settings.

The problem

Releases ship. Nobody knows what changed.

You tag a release. Engineering knows what's in it because they wrote it. Everyone else finds out when something breaks for them — Customer Success hears it from a customer, Marketing learns the new feature exists when sales asks for a demo, Security discovers the auth refactor in code review the next sprint.

The fix today is a tax engineers pay every release: copy the changelog into Slack, @mention three teams, post into #releases hoping the right people are watching, repeat for staging and production. Half the teams skim, half miss it, and the next release you do it again.

Pipie watches the pull requests you ship and routes each one to the right channel based on the labels already on it. One label per concern, one channel per audience, zero manual notifications.

How it works

Three steps. Then it just runs.

  1. 1 Label your PRs

    Use whatever taxonomy already fits your team

    affects-support, affects-marketing, security-review, breaking — pipie reads PR labels straight from GitHub webhooks. No new tools, no new conventions.

    Labels on #142
    affects-support affects-marketing security-review
  2. 2 Map labels to channels in pipie

    One mapping per label per channel. * for catch-all.

    Pick the Slack channel from a dropdown — pipie reads the workspace channels you have access to. Same UI for both providers.

    /repositories/.../release-channels
    Label Channel
    affects-support #support
    affects-marketing #marketing
    security-review #security
    * #all-releases
  3. 3 Tag a release. Channels light up.

    An intro message names the release, then one message per PR follows.

    Each channel gets only the PRs relevant to it. The PR's ## Release Notes section becomes the message body — what you wrote in the PR is what your team reads in Slack.

    #support
    Pipie
    Pipie 03:40
    :package: *Release v1.4.2 has been released* Repository: acme/auth-service
    Pipie
    Pipie 03:40
    • <https://github.com/acme/auth-service/pull/142|Auto-suspend free trial after 14 days> Notifies the customer 24h before suspension and auto-cancels the subscription if no card is on file.
    Pipie
    Pipie 03:41
    • <https://github.com/acme/auth-service/pull/144|Add billing-history export> Users can now export their invoices to CSV from the billing settings.

What it does

The details that matter

Per-label routing

Different PRs in the same release land in different channels based on each PR's own labels.

Wildcard catch-all

Map * to any channel and you'll see every PR in every release — perfect for an "all releases" channel.

Per-channel dedup

A PR with multiple labels mapped to the same channel posts there once, not once per label.

Auto release notes

Pipie pulls the ## Release Notes section from the PR description and uses that as the channel message body.

No extra OAuth

Pipie reads GitHub via your existing webhooks — no extra scopes, no rate-limit headaches, no “please give us API access” asks.

Both providers, one config

Same mapping UI works for GitLab and GitHub. Use one or both — pipie handles each repo independently.

Pricing

Release tracking is on the Pro and Enterprise plans

See the full pricing page for everything else included.