Notifications

Overwatch pushes results out as notifications: emails and chat webhooks, configured per organization with optional per-site overrides. All notification-settings endpoints are session-only (owner/admin) — receiver config is dashboard administration, not something a CMS key can change.

The four kinds

Each kind has its own recipient list, so on-call, editorial, and stakeholder audiences stay separate:

Kind	Fired when	Receivers
Uptime incidents	A monitor goes down or recovers (multi-region consensus)	uptimeRecipients, uptimeWebhooks
Crawl summaries	A crawl finishes (broken links + accessibility summary)	crawlReportRecipients
Performance regressions	A site’s Core Web Vitals verdict flips from pass to fail	perfAlertRecipients, perfAlertWebhooks
Stakeholder reports	The scheduled branded PDF report goes out	reportRecipients

Recipients are either org members ({ "kind": "user", "userId": … } — resolved to the member’s current email at delivery time) or external addresses ({ "kind": "email", "email": … }). Webhooks support slack, discord, and teams (formatted for the chat app) plus generic http (a structured JSON POST to any endpoint).

Org defaults and per-site overrides

Settings live at two scopes:

• Org defaults — GET/PATCH /v1/notifications: the baseline receivers for every site.
• Per-site overrides — GET/PATCH/DELETE /v1/sites/{id}/notifications: client isolation, so one site’s alerts stay out of another client’s channels. An override starts from empty receivers with includeOrgDefaults: true — the org defaults still apply until you set includeOrgDefaults: false, so a partial save can only narrow delivery deliberately, never by accident. Deleting the override reverts the site to the org defaults.

Uptime monitors additionally carry their own alertEmails/alertWebhooks, delivered on top of whatever the settings resolve to.

Changes take effect on the next delivery — settings are read at send time.

Testing a channel

POST /v1/notifications/test delivers a one-off test message to a single email or webhook — synchronously, so a 200 means it arrived and a 502 carries the delivery error. Targets don’t need to be saved first, so you can verify a webhook URL before committing it.