Per-channel filtering for Issue notifications (route by deployment_environment)

[filippetrovic]

TL;DR

Allow each channel attached to an Issues configuration to carry its own optional SQL WHERE clause, AND-combined with the issue-level filter. This lets users route staging issues to #eng-alerts-staging and production issues to #eng-alerts without having to maintain two parallel Issues configs or merge everything into one channel.

Default behavior unchanged (empty per-channel filter ≡ today's "every enabled channel gets everything"), so this is strictly additive.

Problem

Today, when configuring notification channels for Issues (Settings → Issues → Configure), all enabled channels receive every issue that passes the issue-level WHERE filter. There is no way to send different environments to different channels — e.g. staging issues to #eng-alerts-staging and production issues to #eng-alerts.

The only workarounds are:

1. Send all issues to a single combined channel (loses separation; noisy for on-call).
2. Send every issue to both channels (defeats the purpose of separating them).
3. Use the issue-level WHERE to restrict to one environment, which forces the other environment to be either dropped or handled by a separate project.

Concrete current state (from our config):

• Channels: eng-alerts-staging, eng-alerts — both enabled.
• Custom SQL filter: deployment_environment IN ('staging', 'production').
• Result: both channels get both environments.

Proposal

Add an optional per-channel WHERE clause on the Issues Configure page, AND-combined with the top-level issue filter. Same SQL syntax as the existing filter; NULL / empty = current behavior.

Rough UI shape (extending what's already there):

Channels
  [x] eng-alerts-staging   [edit]  ▼ Filter (optional)
       deployment_environment = 'staging'

  [x] eng-alerts           [edit]  ▼ Filter (optional)
       deployment_environment = 'production'

Advanced Options
  [x] Enable custom SQL WHERE clause filter
      deployment_environment IN ('staging', 'production')

Semantics: a channel receives an issue iff channel.filter_where IS NULL OR (channel.filter_where evaluates TRUE for the triggering span). AND'd with the existing issue-level filter.

Why this shape

An alternative would be a routing-rules table (condition → channels). That's more powerful but introduces several new concepts (rule order, fan-out semantics, precedence vs. the top-level filter). The per-channel filter above:

• Is strictly additive — existing configs behave identically (default filter_where is NULL).
• Reuses an input users already understand (same syntax as the existing issue-level filter).
• Generalizes naturally to anything beyond deployment_environment (service, severity, tenant, etc.).

Scope notes

• Issues only. Alerts use the same flat channel_ids shape (visible in the Terraform provider — AlertRead.channels in terraform-provider-logfire/internal/client/client.go:708), so the same pattern could later extend to alerts, but that's a separate ask.
• Once this ships, it would be useful to expose it via the Terraform provider. Today, issue configuration is not represented as a logfire_issue resource at all — a separate but related gap for IaC users.

Related

Searched open & closed issues; this doesn't appear to be filed. Closest adjacent ones: #1156 (docs question about filtering alerts by environment), #1507 (webhook body transform), #1045 (webhook payload templates) — all different concerns.

[bsarahnjason-ops]

TL;DR

Allow each channel attached to an Issues configuration to carry its own optional SQL WHERE clause, AND-combined with the issue-level filter. This lets users route staging issues to #eng-alerts-staging and production issues to #eng-alerts without having to maintain two parallel Issues configs or merge everything into one channel.

Default behavior unchanged (empty per-channel filter ≡ today's "every enabled channel gets everything"), so this is strictly additive.

Problem

Today, when configuring notification channels for Issues (Settings → Issues → Configure), all enabled channels receive every issue that passes the issue-level WHERE filter. There is no way to send different environments to different channels — e.g. staging issues to #eng-alerts-staging and production issues to #eng-alerts.

The only workarounds are:

1. Send all issues to a single combined channel (loses separation; noisy for on-call).
2. Send every issue to both channels (defeats the purpose of separating them).
3. Use the issue-level WHERE to restrict to one environment, which forces the other environment to be either dropped or handled by a separate project.

Concrete current state (from our config):

• Channels: eng-alerts-staging, eng-alerts — both enabled.
• Custom SQL filter: deployment_environment IN ('staging', 'production').
• Result: both channels get both environments.

Proposal

Add an optional per-channel WHERE clause on the Issues Configure page, AND-combined with the top-level issue filter. Same SQL syntax as the existing filter; NULL / empty = current behavior.

Rough UI shape (extending what's already there):

Channels
  [x] eng-alerts-staging   [edit]  ▼ Filter (optional)
       deployment_environment = 'staging'

  [x] eng-alerts           [edit]  ▼ Filter (optional)
       deployment_environment = 'production'

Advanced Options
  [x] Enable custom SQL WHERE clause filter
      deployment_environment IN ('staging', 'production')

Semantics: a channel receives an issue iff channel.filter_where IS NULL OR (channel.filter_where evaluates TRUE for the triggering span). AND'd with the existing issue-level filter.

Why this shape

An alternative would be a routing-rules table (condition → channels). That's more powerful but introduces several new concepts (rule order, fan-out semantics, precedence vs. the top-level filter). The per-channel filter above:

• Is strictly additive — existing configs behave identically (default filter_where is NULL).
• Reuses an input users already understand (same syntax as the existing issue-level filter).
• Generalizes naturally to anything beyond deployment_environment (service, severity, tenant, etc.).

Scope notes

• Issues only. Alerts use the same flat channel_ids shape (visible in the Terraform provider — AlertRead.channels in terraform-provider-logfire/internal/client/client.go:708), so the same pattern could later extend to alerts, but that's a separate ask.
• Once this ships, it would be useful to expose it via the Terraform provider. Today, issue configuration is not represented as a logfire_issue resource at all — a separate but related gap for IaC users.

Related

Searched open & closed issues; this doesn't appear to be filed. Closest adjacent ones: #1156 (docs question about filtering alerts by environment), #1507 (webhook body transform), #1045 (webhook payload templates) — all different concerns.