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

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

Plans

Enterprise and MSP

Permission

incident:manage

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.

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 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.
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.
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
• Notification channels
• Incidents