# Bulk assign notifications — "Deployments & failing deployments" attaches only the *completed* event, never *failed*

**Project:** Bugs | **Board:** Planned | **Votes:** 2
**URL:** https://roadmap.ploi.io/projects/7-bugs/items/1591-bulk-assign-notifications-deployments-failing-deployments-attaches-only-the-completed-event-never-failed

---

Hi,

I think there's a bug in **Profile → Notification channels → Bulk assign notifications**. It
reports success but attaches the opposite of what the option describes, and because it reports
success there's nothing to indicate anything went wrong.

**Account:** user ID 32316 (MattAppleton), team 12648.

### Steps to reproduce

1. Create an e-mail notification channel (mine: label `deploy fails`, channel ID **8852**).
2. Go to **Profile → Notification channels → Bulk assign notifications**.
3. Tick that channel under *Notification channels*.
4. Under *Notification type → Site notifications*, select **"Deployments & failing deployments"**.
5. Under *Select sites*, click **Select all** (27 sites in my account).
6. Click **Assign notifications**.

### Expected

Given the option is named "Deployments & failing **deployments**", each selected site gets a
notification on failed deployments — or, at minimum, on both completed *and* failed.

### Actual

Every selected site gets a rule for the **"Deployment completed"** event only. **No site gets a
"Deployment failed" rule.** The UI reports:

> Notification channels have been assigned (27 attached, 0 skipped)

and the channel's *Total Usages* column increments to 27, so it looks entirely successful.

### Evidence

Immediately after the bulk assign, requesting a site's notifications page with the Inertia headers
(`GET /panel/servers/92910/sites/324896/notifications`) returns:

- `props.attachedNotifications` (deployment completed) → **contains channel 8852**
- `props.attachedDeployFailedNotifications` → **`[]`**
- `props.attachedDeployStartedNotifications` → `[]`

The site's own **Notifications** page shows the same thing — a single row reading
`deploy fails | Deployment completed | email`.

Example sites affected: server 92910, sites 324747 (`tavinstitute.org`) and 324896
(`staging2025.tavinstitute.org`). Bulk assign performed 2026-09-03 ~15:51 UTC+1.

### Impact

This is the inverse of the intent, and it fails silently in both directions:

- **No alert when a deployment fails** — the exact event people set this up for. I'd just spent a
  day tracing a production deploy that had been failing unnoticed since the previous night, so
  this was the specific hole I was trying to close.
- **An e-mail on every successful deployment** across every selected site — noisy enough that the
  natural response is to switch the notifications off again.

Because the confirmation message and the usage count both say it worked, there's no signal to
check. I only caught it by inspecting the Inertia props.

### Workaround

Set each site individually: **Site → Notifications → Deploy notifications**, Event = *Deployment
failed*, Channel, **Save**. This works correctly and posts to
`POST /panel/servers/{server}/sites/{site}/notification-channels/deploy-failed` with body
`{"id":"<channel id>"}`. I had to do this for all 27 sites and delete the 27 incorrect
"Deployment completed" rules the bulk assign had created.

### Suggested fix

Either:

1. Make "Deployments & failing deployments" attach **both** the `deploy` and `deploy-failed`
   events (matching the label); or
2. Split it into separate selectable options — *Deployment started* / *Deployment completed* /
   *Deployment failed* — mirroring the per-site form, which already offers exactly those three.

Option 2 seems closer to what the per-site UI does, and would let people subscribe to failures
only, which I'd guess is the common case.

### Minor, possibly related

On the same bulk-assign screen, the *Select sites* list only includes sites that have a
repository. That's sensible and I'm not asking for it to change — just noting it in case the two
areas share code, since it means the site count there won't match the account's total site count
(27 of 59 in my case).

Thanks,
Matt