Alerts and notifications
Being told when a workload is in trouble, and choosing where that message lands.
On this page
Two halves
Alerts decide when something is worth saying, and they are configured per project. Channels decide where it is said, and they belong to the organization so several projects can share one.
An alert with no channel still shows on the project's Alerts page, but nobody is told. A channel carries more than alerts: deploys, restarts, failures and billing events for every project in the organization, filtered by the minimum severity you give it.
Setting up a channel
- Go to Notifications in the organization.
- Add a channel: Slack, Microsoft Teams, email, or a generic webhook.
- Send a test message. Do this now rather than finding out during an incident that the webhook URL was wrong.
Emails
Even without a channel, the owners and admins of an organization are emailed when an app keeps crashing or cannot start, a domain still has no certificate an hour after you added it, or a backup fails, at most once per incident per day. Turn it off for the organization under Notifications once a channel receives incidents.
Everyone chooses their own mail under Emails on their Account page: getting-started tips, release notes (at most once a week) and incidents each have a switch. Sign-in codes, invitations, security notices, billing and support replies always arrive.
Choosing thresholds
A fixed set of alerts is always on: crash loops, containers killed for running out of memory, pods not ready for 10 minutes, failed release commands and scheduled jobs, and PostgreSQL trouble. Three fire on sustained resource pressure rather than on a single spike, and have a threshold you set:
| Alert | Fires when |
|---|---|
| CPU | Usage stays above the threshold, as a share of the app's CPU limit. Apps on paid plans have no CPU limit, so this only fires where one is set |
| Memory | Usage stays above the threshold |
| Volume | A volume fills past the threshold |
Volume is the one worth setting carefully. CPU and memory pressure degrade a workload; a full disk stops it, and often takes the data with it.
Thresholds you never act on train you to ignore the channel. If an alert has fired weekly for a month and nobody has done anything, either raise the threshold or fix the workload. A noisy channel is worse than no channel, because it hides the one that matters.
Settings reference
| Setting | Default | What it does |
|---|---|---|
| Enabled | on | Whether this project alerts at all. |
| CPU threshold | 80% of the limit | Sustained CPU above this notifies. |
| Memory threshold | 80% of the limit | Sustained memory above this notifies. |
| Volume threshold | 85% of capacity | A volume filling past this notifies. |
| Channel | every channel in the organization | Firing alerts go to each channel whose minimum severity they meet. Configured per organization. |
Limits and gotchas
- Alerts are per project. Every new project starts with them on at the default thresholds, so tune them rather than switching them on.
- Channels are per organization. Removing one silences every project that used it.
- This is not an uptime monitor. Alerts describe your workloads from the inside. Whether a visitor can reach your site is a different question, and one an external check answers better.
- Nobody is paged. A message lands in a channel; it does not escalate and does not wake anybody up.
Related
- Volumes, the resource whose alert matters most.
- When something is wrong for what to do once one fires.