Notifications
The Notifications tab is where you wire this project's experiment and flag events to the destinations your org has connected. It also shows the delivery log for this project alone. That way an experiment owner can confirm a winner notification actually fired in Slack, without digging through every project's history.
- The Notifications tab, in the settings tab strip.
- A connected destination's event checkbox grid, grouped under headings like Experiment lifecycle, Analytical, Safety, and Feature flags. The full group list is in the table below.
Destinations live under Organization Settings → Integrations. Slack, Teams, Jira, and webhooks (an automatic request A vs B sends to your own server) all connect there. They're shared across every project. The Notifications tab below decides which destinations receive which events from this project.
Accessing the Notifications tab
Open your project, click the gear icon in the left sidebar to open Project Settings, then click the Notifications tab. The tab has three sections.
1. No-destinations banner
If your organization hasn't connected any notification destinations yet, the Notifications tab opens with an info banner that links straight to Organization Settings → Integrations. Once a destination is connected at the org level, the banner disappears and the routing panel below becomes useful.
2. Notification routing
The Notification routing panel lists every destination your org has connected. For each one, a grid of checkboxes lets you decide which event types from this project fire on it. A few terms come up in the list below:
- A variation (one specific version being tested, control or one of the challengers).
- A guardrail (a metric you're not trying to improve but don't want to make worse, like page load time).
- SRM (short for sample ratio mismatch: the traffic split you're seeing doesn't match what you configured).
- A feature flag (a setting in your code that can be turned on, off, or changed without a new deploy).
- An exclusion group (a rule that keeps a visitor from landing in two conflicting experiments at once).
The full list has 25 events. They're grouped the same way on screen as in the table below:
| Group | What it means | Events |
|---|---|---|
| Experiment lifecycle | Someone started, paused, or changed an experiment. | Launched, paused, resumed, completed; changes published; visual editor change set saved |
| Analytical | Results worth reading, sent on a schedule or when a call is made. | Winner declared; daily results digest |
| Safety | Something looks wrong with the data. These ignore your organization's keyword gate. | SRM check failed; traffic guardrail breached; guardrail metric breached; variation code error detected |
| Feature flags | Flag rollouts, plus the same analytical and safety alerts for A/B rules. | Published; rule activated; SRM check failed; guardrail breached; daily results digest |
| Organization | Changes to org-wide settings that affect every project. | Exclusion group created, updated, deleted |
| Background work | Imports, syncs, and recommendation runs: the jobs that otherwise fail quietly. | Job failed; import completed; recommendation run completed; dataset version activated; catalog feed sync completed |
Feature-flag A/B rules raise the same alerts as experiments
A feature-flag rule that runs as an A/B test is a real experiment. So it gets the same three analytical events a regular experiment gets. These are separate toggles, so you can send flag-rule alerts somewhere different from your experiment alerts:
| Event | When it fires |
|---|---|
flag.srm_failed | The rule's SRM check goes red: visitors aren't landing in the split you configured, so the numbers can't be trusted yet. Checked whenever the rule's results are recomputed. |
flag.guardrail_breached | The rule's traffic-health check goes red: a variation has too few visitors to read. |
flag.results_ready | The daily digest, once per running A/B rule per day. |
The two safety events ignore the keyword gate, exactly like their experiment counterparts. A broken split is worth knowing about, whether or not the rule's name matches one of your organization's keywords. The daily digest respects the gate.
Each of these fires at most once per rule per day, no matter how many times someone opens the results page. A rule only ever alerts on its official engine. Previewing the results under a different engine never raises an alert.
Routing is per project. The same Slack channel can hear about storefront experiments from one project, while a separate channel covers an experimental microsite, all from one workspace connection.
Editing routes requires the manageIntegrations permission. Read-only viewers see the same panel with the checkboxes disabled.
"Coming soon" events
Occasionally a row is greyed out with a Coming soon badge and can't be turned on. The notification itself is real, and its message template exists. But the part of the app that would actually send it is still being built, so subscribing would promise an alert that never arrives. The toggle turns on by itself, with nothing for you to do, the moment that piece ships.
Nothing is in that state today: every event in the table above can be routed right now.
3. Deliveries
Below the routing panel is the project's Deliveries log. It lists every notification attempt for events routed from this project, with filters for status (delivered, failed, permanent failure, pending) and event type. Failed deliveries can be replayed inline.
For the organization-wide deliveries log (every project's notifications in one view), see Organization Settings → Integrations.
Notifications tab vs. Integrations tab
These are two different tabs in Project Settings, easy to confuse:
- Notifications (this tab) decides where events from this project are sent: Slack, Teams, Jira, webhooks.
- Integrations decides how this project reports its experiment-view events to client-side analytics: Google Analytics, Mixpanel, Segment, etc.