---
title: "Alerts"
description: "Decide what is worth waking somebody for, route it to the right person, and keep one problem from sending fifty messages."
url: "https://support.outpostplatform.com/guides/alerts/"
product: "depot"
type: "how-to"
status: "stub"
ai_summary: "Guide to Outpost alerting. Alerts are evaluated on the server against thresholds in the policy catalogue, deduplicated per open source so one problem produces one alert, routed by rules to email, chat and other channels, and escalated when nobody acknowledges them."
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/guides/alerts.md"
license: "CC BY 4.0"
---

# Alerts

An alerting system earns its keep by what it does not send. Outpost evaluates
alerts on the server, keeps one open alert per problem rather than one per
check, and routes by rule so that the person who can fix something is the person
who hears about it. This guide is for whoever is on the receiving end and
whoever decides who that is.

<!-- TODO: write this page against the how-to template.

Sections:

- Before you begin: the alert permissions and at least one channel set up.
- What raises an alert, and where the thresholds live.
- Severities, and what each one is meant to mean.
- Deduplication: one open alert per source, and what that means in practice.
- Routing rules: matching on client, group, severity and category.
- Channels, and what each one is good for.
- Acknowledging, resolving, and what happens if nobody does either.
- Escalation, and setting a sensible ladder.
- Quiet hours and suppression during known work.
- If something goes wrong: too many alerts, no alerts, and alerts for
  endpoints that are simply being enrolled.
-->

Follow the [how-to template](https://gitlab.com/outpostplatform/docs/-/blob/main/templates/how-to.md).