Notifications & webhooks

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.

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. 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. It’s also held during a platform-wide maintenance window or connectivity incident that Alpacon itself starts—see Maintenance windows.

Direct logins#

When 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 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 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 for that wait, the alert email’s subject, and who it’s sent to. Define rules on the Metric alerts screen of the Metrics app, and see what a rule can carry 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 Preferences > Notifications—or from the Server alerts card’s warning row, which is the same setting; see Notification preferences below. It also appears in your in-app feed each time it’s sent.

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.

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. The subject starts with [Critical] and names the workspace and the session, and the email links to the session’s analysis. It isn’t posted to Slack.
• High: an in-app notification and an email with a subject starting [High].
• Below High: no notification.

Channels and where they’re configured#

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.

Notification preferences#

Open Notification preferences from the account menu at the bottom of the left sidebar, or go to Preferences > Notifications directly. The page opens with a Server alerts card, then the Browser notifications card, then the full grid of categories and channels.

Server alerts#

The Server alerts card summarizes what each alert severity does and gives you the two switches that are actually yours to change. Each switch is the same setting the grid below has for that category and channel—flipping it here or finding the matching row in the grid changes the identical thing, since severity itself isn’t a separate saved setting.

• Critical: email and the team’s Slack channel—the Email me critical threshold alerts switch is your own copy of the server category’s threshold-alert email. If a rule is set to send no email at all, turning this on still won’t deliver anything.
• Warning: the team’s Slack channel, plus an hourly summary email to admins—the Email me the hourly summary switch is the same setting as the Open alert digest category’s email channel in the grid.
• Info: bell only. Nothing to turn off. There’s no switch on this row.

Both severities can post to the team’s Slack channel when the rule they came from has that turned on—it’s a per-rule setting, not a personal one; click Open alert rules on the card to review or change which rules post there. A switch locks off, greyed out, when the setting behind it is off for another reason—for example, when you’ve already turned off all of Server email in the grid below, or your workspace requires the channel and won’t let anyone turn it off. On a deployment that predates event-level preferences, the card shows the three descriptions with no switches at all.

The card has its own address in the app—#server-alerts—so a link to it opens the page and scrolls straight there instead of to the top.

Turning off a single event#

Expand a category row in the grid to see the events inside it. Where the server offers per-event control for that category and channel—Servers email is one—the events fold into a switch each, instead of the plain list of what the channel covers; a cell that isn’t offered this yet still lists its events, just without switches to flip.

Turning off a whole cell—the category’s box for one channel—turns off every event switch inside it too: they show unchecked and locked while the cell stays off. An event you’d separately turned off before still carries a small Also off on its own tag, so turning the cell back on won’t quietly re-enable that one event without you noticing. While a cell is on and only some of its events are off, it shows a tag such as 3 off; click it to expand the row and see which ones.

Restoring a whole channel—clicking the unchecked box in that column’s header—reverts every category-wide setting and every individual event you’d turned off in that column, not just the category-level ones.

Webhooks#

A webhook posts notification events to an external service so they land in a channel your team already watches. Alpacon formats each message for the destination automatically, so a Slack webhook reads as a Slack message and a Teams webhook as a Teams card. Supported destinations are Slack, Discord, Microsoft Teams, Telegram, and custom HTTP endpoints, detected from the URL you enter.

To add one from the product:

1. Go to Workspace settings > Integrations > Webhook.
2. Click New webhook.
3. Enter a Name and the URL. Leave Provider on auto-detect unless you need to override it, keep Verify SSL on for public endpoints, and set Enabled.
4. Save.

For step-by-step provider setup, such as creating the incoming-webhook URL in Slack, Discord, Teams, or Telegram, see Webhook setup. To create and manage webhooks from the command line, including the message payload and provider options, see the webhook CLI reference.

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—Preferences > 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 above. 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.

Plan availability#

Email notifications, 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; for the full plan lineup, see the pricing page.

Manage from the CLI#

The Alpacon CLI mirrors these settings:

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

Related docs#

• Manage workspace settings
• Maintenance windows
• Plans & billing
• Approvals
• Webhook CLI reference