Where notifications go: in-app, email and webhooks
Reading · 5 min · Module 6, lesson 3 of 530 min left in this module
Module 6 · Monitoring and alertsLesson 3 of 5
Goal: Choose which events notify you and send them to a team chat channel through a JSON webhook.
Key idea
Notification settings are yours, not the project's: you pick the events, then the channels they go to. A webhook channel lets you send them anywhere that accepts an HTTP request, such as your team's chat.
Where to set them
Open Settings from the console's main menu and choose Notifications. There are two cards.
Events is what you want to hear about: Billing & invoices, Payment reminders, Deployment status, Activity alerts and Account & team. Notifications from alert rules count as Activity alerts.
Delivery channels is where they go:
In app: the bell at the top of the console.
Email: to the Recipients you list, which can include a shared team address as well as your own.
Webhook: an HTTP POST to each endpoint you add.
Every event you turn on goes to every channel you turn on. Choose Save changes when you're done.
The settings belong to you and cover every project in the account. A teammate who wants the same notifications turns them on in their own settings.
Webhooks
Turn on Webhook and choose Add webhook endpoint. Each endpoint has:
URL: where to send it, such as a chat tool's incoming-webhook address.
Token: optional. When set, it's sent as Authorization: Bearer <token>, for receivers that check who's calling.
Format: JSON or Text.
Choose JSON for chat tools. The body carries the same message in three fields, because different tools read different ones:
{"text": "…", "content": "…", "message": "…"}
Slack-style incoming webhooks read text; Discord-style ones read content. Each ignores the fields it doesn't know.
Before and after
Saving an endpoint doesn't prove it works; the first real notification does. So set up the receiving end first and check it answers, and remove an endpoint before you delete whatever it points at.