---
title: "Alerts"
description: "How Outpost raises one alert per condition on an endpoint, how to read the alert queue, and how to acknowledge, resolve, or promote an alert."
url: "https://support.outpostplatform.com/service-desk/alerts/"
product: "depot"
type: "how-to"
status: "draft"
ai_summary: "Alerts on every plan: one per condition per endpoint; open, acknowledged, resolved; critical, warning, info. Thresholds are profile policy settings. Disk alerts are per fixed drive (C:, /); memory uses real system memory; CPU reads the 15-minute average after a 15-minute warm-up. Old alerts naming the agent's data folder close on their own. Acknowledge, resolve, who was told, promote to incident."
availability:
  plans: ["home-lab", "essentials", "enterprise", "msp"]
  permission: "alert:ack"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/service-desk/alerts.mdx"
license: "CC BY 4.0"
---

# Alerts

An alert is Outpost's record that something on an endpoint needs attention,
such as a disk running out of space, a watched service that stopped, or an
endpoint that went offline. This page explains how alerts are raised and how
to work the alert queue: read it, take an alert, resolve it, and turn it into
an incident when it is part of a wider outage.

Who is notified about an alert is decided by
[alert rules](/service-desk/alert-rules/) and
[notification channels](/service-desk/notification-channels/).

## How alerts are raised

Outpost evaluates what endpoints report and raises an alert when a condition
is met. Most thresholds are policy settings on the endpoint's profile, so they
can differ between sites, device groups, and endpoints. See
[Profiles](/automation/profiles/).

| Policy setting | Default | What it raises |
| --- | --- | --- |
| `monitoring.disk_free_warn_percent` | 15 | A warning when free space on a drive is at or below this percentage. |
| `monitoring.disk_free_critical_percent` | 5 | A critical alert when free space on a drive is at or below this percentage. A drive at or below both thresholds raises only the critical alert. |
| `monitoring.cpu_sustained_warn_percent` | 90 | A warning when the 15-minute average processor use is at or above this percentage. |
| `monitoring.memory_used_warn_percent` | 90 | A warning when memory in use is at or above this percentage of the endpoint's total memory. |
| `monitoring.agent_offline_alert_minutes` | 30 | An offline alert after this many minutes without a heartbeat. `0` turns it off. |
| `monitoring.service_watchlist` | Windows security and core services, and the Outpost agent services | An alert when a listed service stops, and when its start type changes. |
| `monitoring.alert_on_service_stop` | On | Whether a watched service stopping raises an alert. |
| `monitoring.process_watchlist` | Empty | A critical alert in the **Process** category for each listed process that is not running, such as **Watched process sqlservr is not running**. It clears when the process runs again. Names match without regard to case, with or without `.exe`. |
| `monitoring.alert_on_new_admin_account` | On | An alert when an account is added to the local administrators group. |

Other parts of Outpost raise alerts of their own, such as vulnerability
findings, failed patch installs, USB and driver activity, backup failures,
documentation expiry reminders, and network discovery findings.

### What disk, memory, and CPU alerts measure

The agent reports these figures each time it checks in:

- **Disk**: every local fixed drive, with its total and free space. Windows
  names a drive by its letter, such as `C:` or `D:`. Linux, FreeBSD,
  OpenBSD, and macOS name it by its mount point, such as `/` or `/boot/efi`.
  Removable, optical, and network drives are not reported and never raise a
  disk alert. Each drive has its own alert, titled with the drive's name, such
  as **Disk space low on D:**. When a drive stops being reported, for example
  because it was removed, its alert resolves.
- **Memory**: the endpoint's total memory and the memory available to new
  programs. Memory in use is total minus available. Memory the operating
  system can reclaim on demand, such as file cache, counts as available, so a
  full cache on its own does not raise a memory alert.
- **CPU**: processor use averaged over the last 1, 5, and 15 minutes, measured
  once a minute. The CPU alert reads the 15-minute average only, so a short
  spike, such as a backup starting, does not raise it.

An average is reported only when the agent has measured for its whole window.
For the first 15 minutes after the agent starts, such as after a restart or an
update, the endpoint sends no 15-minute figure, and Outpost neither raises nor
resolves a CPU alert for it. A dropped connection does not restart the window.

:::note
Disk alerts raised before an endpoint's agent was updated can name the agent's
data folder, such as `C:\ProgramData\Outpost`, instead of a drive. Each one
resolves as **The condition cleared on its own** at the endpoint's first
check-in on the updated agent. Alert rules that tell channels when a condition
clears send a message for each.
:::

### One alert per condition

Each condition has one live alert. When a condition keeps firing, Outpost does
not raise another alert. It adds to the **Times seen** count on the alert it
already has and updates **Last seen**. **First seen** stays the time the
condition started. An acknowledged alert still counts as live, so the same
problem never appears in the queue twice.

When the condition is over, the alert is resolved. If the condition happens
again later, it raises a separate alert with its own first-seen time.

## Severities, states, and categories

Every alert has one severity:

| Severity | Meaning |
| --- | --- |
| **critical** | Needs action straight away, such as free space on a drive at or below the critical threshold. |
| **warning** | Needs attention, but not straight away. |
| **info** | Worth knowing, with no action expected. |

Every alert is in one state:

| State | Meaning |
| --- | --- |
| **open** | Raised, and nobody has taken it. |
| **acknowledged** | A technician has taken it. The condition may still be present. |
| **resolved** | Finished. The alert detail says how it ended. |

An alert ends in one of four ways, shown under **Resolved** on the alert:

- **The condition cleared on its own**: Outpost saw the condition end.
- **Closed by hand**: a technician selected **Resolve**.
- **Aged out without clearing**: the alert was not seen again for 7 days.
  This applies mostly to alerts about events, such as a USB device being
  connected, which have no "cleared" signal.
- **Endpoint retired**: retiring the endpoint resolves its open and
  acknowledged alerts and cancels pending escalations. It does not mean the
  triggering condition cleared.

Resolved alerts are kept for 90 days.

The **Category** column says what kind of condition an alert is about:
**Offline**, **Disk**, **Memory**, **CPU**, **Service**, **Script**,
**Security posture**, **Endpoint event**, **Vulnerability**, **Patching**,
**Device activity**, **Network activity**, **Project**, **Documentation**,
**Network discovery**, **Backup**, or **Process**.

## Before you begin

- To read alerts, you need `alert:read`. To acknowledge and resolve them, you
  need `alert:ack`. See [Roles and permissions](/depot/roles-and-permissions/).
- To see who was notified about an alert, you need `alert:manage`.

## Read the alert queue

1. Select **Alerts** > **All alerts**. On the MSP plan, open a client first,
   or select **Inbox** > **Alerts** to see live alerts across every client.
2. Choose a view. The queue opens on **Live**: every open and acknowledged
   alert, worst first.

   | View | Shows |
   | --- | --- |
   | **Live** | Open and acknowledged alerts, by severity. |
   | **Critical, not yet taken** | Open critical alerts, most recently seen first. |
   | **Being worked** | Acknowledged alerts. |
   | **Everything** | Every alert, including resolved ones. |

3. To narrow the list, add a filter on **State**, **Severity**, **Category**,
   or **Last seen**, or type in **Find an alert**. The search matches the
   alert title only, not the detail or the endpoint name. To find the alerts
   for one endpoint, open the endpoint and select its **Alerts** tab.

Alert views show current endpoints by default. Select **Include retired
endpoints** to include retired endpoints' alerts.

Combined open and acknowledged totals are labeled **Unresolved**.
Acknowledging takes responsibility for an alert; it does not mean the problem
is remediated.

When no notification rules are active, the queue warns: **No notification
rules are active. Alerts are recorded but nobody is notified.**
[Create or enable an alert rule](/service-desk/alert-rules/) to send
notifications.

You can save your own views from the toolbar.

## Acknowledge an alert

Acknowledging tells your team that somebody has taken the alert. It also stops
any [escalation steps](/service-desk/alert-rules/#escalation) that have not
run yet.

- In the queue, select **Acknowledge** on an open alert.
- Or open the alert, enter a **Note (optional)**, and select **Acknowledge**.

## Resolve an alert

Resolve an alert when the work is finished.

1. Open the alert.
2. In **Take this alert**, enter a **Note (optional)** of up to 2,000
   characters, such as what you found or did.
3. Select **Resolve**.

If the condition is still present, Outpost raises a separate alert on the
endpoint's next report.

## See who was notified

Open the alert. The **Who was told** card lists each notification sent for it,
with its channel and state. If no rule matched the alert, the card says
**Nobody was notified about this alert. No rule matched it.**

## Promote an alert to an incident

When an alert is one sign of an outage that affects a service, open an
incident from it.

1. Open the alert.
2. Select **Promote to incident**.

The incident opens with the alert's title, severity **Critical** for a
critical alert and **Major** for anything else, and the alert linked under
**Alerts that led here**. It is not shown on the status page until you choose
to publish it. See [Incidents](/service-desk/incidents/).

On a plan without the service desk, the console refuses and names the plan
that includes it, such as **Service desk is available on Enterprise. Upgrade
in the Outpost portal to use it.**

## If something goes wrong

| Symptom | Cause | Fix |
| --- | --- | --- |
| An alert is in the queue, but nobody was notified | No enabled alert rule covers its category, severity, and endpoint. | Check the alert's **Who was told** card, then [create a rule](/service-desk/alert-rules/) that covers it. |
| Too many disk, memory, or CPU alerts | The thresholds are too tight for those endpoints. | Change the policy setting on a profile assigned to those endpoints. See [Profiles](/automation/profiles/). |
| A disk alert names a folder, such as `C:\ProgramData\Outpost`, instead of a drive | It was raised before the endpoint's agent was updated. | Nothing. It resolves at the endpoint's first check-in on the updated agent. If it stays open, the endpoint is still on an earlier agent. See [Agent and tray updates](/agent/updates/). |
| No CPU alert appears, or a CPU alert does not resolve, soon after the agent started | The 15-minute average is not reported until the agent has measured for 15 minutes. | Wait for the first check-in after 15 minutes. |
| A search for a hostname finds nothing | **Find an alert** matches titles only. | Filter by category, or use the endpoint's **Alerts** tab. |

## Next steps

- [Create alert rules](/service-desk/alert-rules/)
- [Notification channels](/service-desk/notification-channels/)
- [Incidents](/service-desk/incidents/)