Feature flags send no notifications: alert a team when a flag is toggled or becomes stale

Feature request

Is your feature request related to a problem?

Feature flags send no native notifications today. There is no built-in way to tell a team that a flag was turned on or off, or that a flag became stale.

An NPS respondent on the Feature Flags survey asked for an automated way to alert their team, for example in Slack, when they turn a flag on or off. Their reason: team members rarely open the flag list themselves, so a change made by one person stays invisible to everyone else. Source: Slack thread.

What exists today

Every other product with a comparable need has a notification surface, but feature flags do not:

The only route for flag changes is a custom Hog destination on the internal $activity_log_entry_created event, filtered to the FeatureFlag scope. It works, and it posts the action, the release conditions, the person who made the change, and a link to the flag: How to get Slack notifications when Feature Flags change.

Two problems with that route:

1. $activity_log_entry_created is not in the destination event picker in the UI, so the destination must be created through the API with a hand-written Hog function. A flag owner cannot do it without an engineer and a personal API key.
2. The tutorial is the only place that documents it. Nothing on the feature flag page points to it.

Staleness has no route at all. PostHog already computes the stale state (not evaluated for 30+ days, or 100% rolled out for 30+ days with no property filters) and shows it as a filter in the flag list, but nothing can react to it. See Cleaning up stale feature flags.

Describe the solution you'd like

Two options, smallest first:

1. Expose $activity_log_entry_created in the destination event picker. Cheapest change. It removes the API-only step and makes the existing tutorial reachable from the UI. It still leaves the user to build the message.
2. A Notifications tab on the feature flag page, the same pattern surveys already use: pick Slack, Discord, Teams, or a webhook, get a pre-filled message template, and the destination is scoped to that flag. Triggers worth covering: flag enabled, flag disabled, rollout percentage changed, and flag became stale.

The stale trigger is the part that needs new work, because staleness is a derived state and not an activity log entry. It needs a scheduled evaluation, not an event filter.

Describe alternatives you've considered

• The API-only Hog destination above. It works for flag change events, but not for staleness, and it is not self-serve.
• An insight alert on $feature_flag_called, broken down by flag, firing when a flag falls under 1 call. This approximates staleness, but it is noisy and does not match the product's own stale definition.
• Querying flag usage through the API on a schedule, outside PostHog.

Additional context

Related: #32163 (notify on stale feature flag), which came from a support ticket and is still open. This request adds the on/off change case and the NPS signal behind it.

Start with the feature flag page, the destination event picker, and the existing $activity_log_entry_created route described in the issue. Compare the survey notification pattern and the stale-flag computation before choosing between exposing the event or building a flag-scoped notification tab. Done means the chosen triggers, destinations, message behavior, and scheduled stale evaluation are specified and covered by tests.