> ## Documentation index
> The full klickops handbook index is at https://klickops.io/llms.txt
> The HTML of this page is at https://klickops.io/en/docs/alerts
> Language: en

# Alerts and notifications

Being told when a workload is in trouble, and choosing where that message lands.

## 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.

Neither does anything on its own. An alert with no channel is a rule nobody hears; a channel with no alert is a pipe with nothing in it.

## Setting up a channel

1. Go to **Notifications** in the organization.
2. Add a channel: Slack, email, a generic webhook, Teams, Telegram or Discord.
3. Send a test message. Do this now rather than finding out during an incident that the webhook URL was wrong.

## Choosing thresholds

Alerts fire on sustained resource pressure rather than on a single spike, and there are three:

| Alert | Fires when |
| --- | --- |
| CPU | Usage stays above the threshold |
| 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.

> [!Careful]
> 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 | off | Whether this project alerts at all. |
| CPU threshold | percent | Sustained CPU above this notifies. |
| Memory threshold | percent | Sustained memory above this notifies. |
| Volume threshold | percent | A volume filling past this notifies. |
| Channel | none | Where the message goes. Configured per organization. |

## Limits and gotchas

- **Alerts are per project.** A new project starts with none, which is a common surprise the first time something fails quietly.
- **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](/docs/volumes), the resource whose alert matters most.
- [When something is wrong](/docs/troubleshooting) for what to do once one fires.