---
title: "Notification events and delivery"
description: "Reference Alpacon notification events, recipients, delivery channels, and plan availability. Use the matrix to choose where your team receives each event."
---

> Full documentation index: https://docs.alpacax.com/llms.txt

# Notification events and delivery

Set your own channels in [Notification preferences](/use/settings/notifications/); to add an endpoint, follow [Webhook setup](/integrate/webhooks/).

## Event and delivery summary

| Event | Recipients | Delivery |
| --- | --- | --- |
| Approval request in a work session | Eligible approvers | In-app, email and, when connected, Slack; later requests in the same session share a thread |
| Work session nearing expiry | Requester and assignee | In-app and, on Alpacon Cloud with browser notifications enabled, browser notification |
| Open alert digest | Workspace admins | Email and in-app feed when the digest is sent |
| Critical session risk analysis | Server owner and workspace Superusers | In-app, email and the connected Slack security channel |
| High session risk analysis | Server owner and workspace Superusers | In-app; email and the connected Slack security channel only when the workspace does not receive periodic reports |

Personal channel choices can turn off eligible email, browser or Slack DM delivery. The in-app feed remains available. The sections below explain each event's timing and exceptions.

## Notification delivery

Alpacon keeps your team informed about what's happening across your servers: approval requests waiting on a decision, security events, monitoring alerts, and servers that go offline. Notifications appear in an in-app feed by default, and can also reach you by email, browser notifications, or Slack DM. Separately, a workspace can forward them to external webhook endpoints.

This page explains what triggers a notification, the channels notifications can reach, and who configures each one. For scripting webhooks, see the [webhook CLI reference](/reference/cli/webhook/).

## What triggers a notification

### In-app notifications

Every member has a notification feed, opened from the bell icon in the top-right corner. It gathers recent activity that's relevant to you, grouped into categories such as:

- **Approvals**: access and command requests waiting on a decision
- **Security**: unauthorized access attempts, direct logins that bypassed Alpacon, insecure open ports, and unknown or relocated devices
- **Servers**: server status changes, including disconnections
- **Work sessions and commands**: session and privileged-command activity
- **Tokens and workspace**: token and workspace changes
- **Monitoring**: metric thresholds crossed on a server

Each item carries a severity of **Info**, **Warning**, or **Critical**. The feed shows your most recent items, and you can mark items as read or dismiss them. It's available to everyone on every plan and needs no setup.

### Server disconnection

Once a server has been offline for five minutes, a **Critical** alert appears in the in-app feed and is delivered by email, plus a post in the workspace's Slack channel if one is connected under [**Integrations** → Slack](/integrate/slack/). It clears on its own when the server reconnects, with a follow-up email and, if it was posted to Slack, a reply in that thread. A server that keeps disconnecting and reconnecting gets one combined notice instead of a message per drop, until the connection settles. The alert stays quiet after maintenance you started through Alpacon, and it can be turned off per server—see [How you're notified](/use/servers/monitor/#how-youre-notified). It's also held during a platform-wide maintenance window or connectivity incident that Alpacon itself starts—see [Maintenance windows](/use/workspace/maintenance-windows/).

### Direct logins

When [detection](/use/audit/governance/external-access/#turn-on-detection) is on, a login that reaches a server without Alpacon and matches no standing entry alerts the workspace's reviewers: a high-risk login by email, the workspace's Slack channel and the in-app feed, any other unexpected login by the Slack channel and the in-app feed. The member an account is bound to is asked "Was this you?" by browser notification, and an Application's maintainers are asked "Was this your automation?" by email. A covered server that stops being covered warns the reviewers too. See [Notifications](/use/audit/governance/external-access/#notifications) on the External access page for who receives each one.

### Metric alerts

A metric alert rule watches a server's metrics and raises an alert when its condition is met, whether that's a threshold breach or a metric going silent—see [Metric alerts](/use/metrics/rules/) for how a rule decides to fire. It appears in the in-app feed and on the dashboard right away; email and the Slack post (if connected) wait about two minutes for the condition to still hold, so one that clears before then never reaches your inbox or Slack. See [Receiving alerts](/use/metrics/rules/) for that wait, the alert email's subject, and who it's sent to. Define rules on the [Metric alerts](/use/metrics/rules/) screen of the Metrics app, and see [what a rule can carry](/use/metrics/rules/) for each field.

### Open alert digest

Once an hour, workspace admins get an email listing the metric and offline alerts that are still open, grouped by severity, along with whatever was newly raised or resolved in the last hour. It's there so a condition that doesn't reach an admin individually—an info-severity rule, a warning-severity rule, or one whose email destination doesn't include admins—still shows up somewhere admins check. A warning-severity alert never sends an individual alert email: it posts to the workspace's connected Slack channel (if that setting is on) and appears here instead. The digest only sends when something changed in the past hour—an alert was raised or resolved. If nothing changed but alerts are still open, admins get a reminder instead, at the first hourly run after 09:00 in the workspace's time zone (UTC if none is set). An hour with nothing open and nothing that changed sends no digest email at all.

The reminder comes every day while the alert stays open. An alert that someone in the workspace has marked as checked or dismissed no longer drives a reminder. Every digest for a workspace carries the same subject, **Open alert digest for** followed by the workspace name, so your mail app keeps them in one conversation; what changed is in the first line of the email instead.

A server whose connection keeps dropping and recovering is announced once as an unstable connection—the same as its individual alert—so those repeated drops don't by themselves trigger the hourly digest. While it's unstable, the digest lists it once as "Unstable connection since …" instead of a new alert every hour. The digest still goes out for any other change during the hour, and once a day as the reminder, exactly as before.

The digest has its own notification category, separate from **Monitoring** and **Servers**, so turning those off doesn't turn off the digest, and the digest's email can be turned off on its own from [notification preferences](/use/settings/notifications/)—or from the **Server alerts** card's warning row, which is the same setting; see [Notification preferences](/use/settings/notifications/). It also appears in your in-app feed each time it's sent.

### Work session expiry

About 5–10 minutes before an approved or active work session ends, its requester and assigned user receive a notice linking to the session. Extend it if you still need access. A new end time gets its own reminder.

The warning appears in the in-app feed and, on Alpacon Cloud, as a browser notification when your browser is registered and notifications are enabled. It is not sent by email or Slack. Being the owner of an assigned API token or of a service token's application does not add you as a recipient; the requester still receives it.

In your notification preferences, turn off **Session expiring soon** to stop its browser notification. Expiry and automatic cancellation notices stay in-app only; revocation also sends browser notifications and email.

### Approval requests in a work session

Approval requests that come up inside one work session, such as held commands and sudo requests, reach each approver as one email conversation per session instead of one email per request:

- The session's first request is emailed right away.
- Later requests are gathered for five minutes and sent together, at most one email per five minutes. A quiet five minutes sends nothing.
- The subject stays the same for the whole session, **Approval needed:** followed by the session title and the requester, so the emails form one thread.
- Each email is complete on its own: new requests in full, requests still waiting in short, and the requests decided or expired since your last email, with who decided them.
- Reminders for a session's pending requests arrive as one summary email in the same thread.

In Slack, the session's first post starts a thread and later requests are posted as replies, each with its own buttons. Once the thread holds more than one request, the first post also shows how many are waiting and their risk levels. A request outside a work session is still sent on its own, one email per request.

### When you can approve your own work session request

If you can approve your own work session request, you're asked first, and the other approvers hear about it about 10 minutes later if it's still open.

This applies when you request a work session, for yourself or for an agent, you are one of its approvers, your workspace's [access rules](/use/approvals/#access-rules) let you approve your own request, and one approval decides it:

- **At once, only you.** The request reaches you in the in-app feed, by email, and, if your Slack account is linked, as a Slack direct message with approve and reject buttons. Email and the direct message follow your [notification preferences](/use/settings/notifications/).
- **About 10 minutes later, everyone else.** If the request is still open, the other approvers are notified and you get a reminder. The approval card is posted to your workspace's Slack approval channel and mentions the other approvers whose Slack accounts are linked.
- **Two more reminders**, to everyone, about 20 and 30 minutes after the request.

If you decide the request before the other approvers are notified, they aren't notified at all; the approval channel still shows the decided card. The other approvers can open and decide the request in the console at any time.

A request that needs more than one approval, or one you can't approve yourself, goes to every approver at once. Sudo, command, and extension requests always go to every approver at once.

If your Slack account isn't [linked](/integrate/slack/#link-members-to-slack), the approval card goes to the approval channel straight away, as it does for any request; the other notifications still go to you alone. You don't get an "approval decided" notification for a request you decide yourself; when another approver decides it, you do.

### Session risk analysis

When AI analysis of a session finishes, the result is sent by how risky it is:

- **Critical**: an in-app notification and an email to the server's owner and the workspace's Superusers.
- **High**: an in-app notification, and the same email only if the workspace doesn't receive periodic reports.
- **Below High**: no notification.

Wherever the email goes, the same notice is also posted once to the workspace's connected Slack channel, the security channel used for direct-login alerts. The email subject and the Slack header are the analyst's first sentence, without a trailing period. The body is one line, `Severity · session · server · approval status`, with the server left out when it has the same name as the session. The approval status is, for example, "Approved by Jane Doe", "2 of 3 approved", or "Ran without approval · Access rule". The message also names the AI agent when known and has a "View analysis" button. The full reasoning and the suggested actions stay in the console.

## Channels and where they're configured

| Channel      | What it is                                                                                | Where it's set up            |
| ------------ | ----------------------------------------------------------------------------------------- | ---------------------------- |
| In-app feed  | The bell in the top bar, one feed per member                                              | Always on, no setup          |
| Email        | Notifications delivered to your inbox                                                      | Per member, Preferences > Notifications |
| **Browser notifications** | Notifications your browser raises (Alpacon Cloud only). The grid below labels this column **Push** | Per member, Preferences > Notifications |
| Slack DM     | A direct message from the Alpacon Slack app                                                 | Per member, Preferences > Notifications |
| Slack channel | A message posted to the Slack channel your workspace connects                              | [**Integrations** → Slack](/integrate/slack/) |
| Webhook      | Delivery to an external endpoint: Slack, Discord, Microsoft Teams, Telegram, or a custom URL | Integrations > Webhook, or the CLI |

Which channels carry a given notification is decided per notification type, not set workspace-wide. Each member can then turn off a channel for a whole category, or for a single event inside it, from their own **Notification preferences**, reachable from the account menu at the bottom of the left sidebar.

Webhooks are the exception and stay workspace-level: open **Workspace settings** in the left sidebar, then **Integrations** → **Webhook** to manage endpoints. A webhook receives notifications once at least one endpoint is registered.

## Who can configure what

Webhooks and metric alerts are workspace-wide: one member configures them and they apply to everyone. Your own delivery channels are personal—[notification preferences](/use/settings/notifications/) lets you turn off email, browser notifications, or Slack DM for a whole notification category, or for a single event inside it; see [Notification preferences](/use/settings/notifications/). That choice affects only you. The in-app feed is always on and cannot be turned off, so nothing is ever lost by turning off a channel.

| Setting                                                       | Who can change it   |
| ------------------------------------------------------------- | ------------------- |
| Your own delivery channels (Preferences > Notifications)       | Every member, for themselves |
| Webhooks (Integrations > Webhook)                              | Staff and Superuser |
| Metric alerts (Metrics > Metric alerts)                        | Operator, Admin or Superuser to create, edit or delete; anyone an Admin has given a rule-scoped role can edit or delete only that rule |
| Your own in-app feed                                           | Every member        |

## Plan availability

Webhooks (including Slack as a webhook destination) and metric alerts require the Essentials plan or higher. On the Free plan the in-app feed still works. Opening **Webhook** brings up an upgrade dialog; **Metric alerts** belongs to the Metrics extension, so the screen itself is replaced by a notice that the plan can't enable it, with a button through to the plans. For how upgrade prompts work and where to change your plan, see [Plans & billing](/use/workspace/plans-billing/); for the full plan lineup, see the [pricing page](https://www.alpacax.com/alpacon/pricing).

## Manage from the CLI

The Alpacon CLI mirrors these settings:

- [`alpacon webhook`](/reference/cli/webhook/)—create, list, inspect, update, and delete webhooks, including the payload format and provider options.

## Self-hosted deployments

On self-hosted deployments, browser notifications aren't available, and email delivery depends on whether your deployment has email configured. The in-app feed and webhooks work on any deployment.

Source: https://docs.alpacax.com/reference/notifications/