Manage servers

Modify server information and control servers remotely.

Edit server information

Change basic information

Click Update button from server list or detail page
You can modify:
- Name: Server identifier
- Authorized groups: User groups with access
- Owner: Server owner
Click Save

Note: Metric alerts are managed in the Metrics app—see Monitor server status - Metric alerts.

Server details

View detailed information in the server detail page:

Overview tab:

Agent information (version, status)
OS information (distribution, version)
System information (CPU, memory, disk)
Operating information (uptime, boot time)
Installed packages
Network interfaces
Offline alert history

Next to the last-synced time, click Refresh now to pull current system information immediately instead of waiting for the next scheduled sync.

Under Network interfaces, Offline alert history lists this server’s resolved offline alerts, newest first, five per page: when each was raised (Raised), when it resolved (Resolved), how long it stood (Stood for), why it closed (Cause), and which channels delivered the resolution (Delivered—the same chips as Alert history). Cause shows a short label with a tooltip carrying the full sentence: Reconnected, Stable again (a flap phase settled), Decommissioned, Disabled, Alert turned off, Deleted, Instance off, No longer applies, or Not recorded for an alert resolved before causes were tracked. Unlike charts and metric alerts, this table isn’t gated by the Metrics extension—it’s available on every plan.

Activity tab:

Command execution history
Server comments and mentions
User activity logs

Access tab:

System users
System groups

Charts and metric alerts live in the Metrics app, not on server detail—see Monitor server status.

Logs tab:

Recent logs from Alpamon agent
Backhaul history (data transmission logs)
Transmission status and data size

Server control

Requirements:

Server status: Connected
Permission: owner or manager of an assigned group, the server’s owner, or a user with the Staff or Superuser role

Agent card

The Agent card on a server’s detail page covers the Alpamon agent itself. Next to the agent’s version, Update policy shows the workspace’s agent update policy: Latest, One release behind, or Manual.

Restart agent: restarts the agent process. Useful for resolving connection issues—the server briefly shows offline and reconnects on its own.
Upgrade agent: updates the agent to the latest release and restarts it. Shown only when the update policy is Manual; under an automatic policy, the agent is upgraded inside the workspace’s maintenance window and no button is shown. On Windows, if the upgrade doesn’t take effect, re-run the installer (see Windows servers).

Click the button, confirm in the dialog, and watch the result in a toast message.

An upgrade never moves an agent to an older version. Under Manual, when the agent already runs the latest release, Upgrade agent stays visible but disabled, with the note Already on the latest release. While an upgrade is already in progress on the server, a second request is refused with “An agent upgrade is already in progress on this server. Try again after it finishes.”

Upgrade history

Under the Agent card, Upgrade history lists this server’s agent upgrades, newest first, five at a time; use Newer and Older to page through them. Automatic and manual upgrades both appear, and anyone who can see the server can see its history.

Each row shows:

Outcome: In progress, Succeeded, Rolled back (the new version didn’t come up cleanly, so the agent went back to the previous one), Failed, Timed out (the agent didn’t confirm the upgrade in time), or Refused (the upgrade was withdrawn before it reached the agent).
Versions: the version the agent moved from and the version it moved to, for example 1.4.2 → 1.5.0. Until the agent reports back, the version it’s being upgraded to is marked (target).
When and who: when the upgrade was requested, and who started it—a member’s username, an API token’s name, or Alpacon automatic policy (latest) for an automatic upgrade.
Reason: for a failed or rolled-back upgrade, why it didn’t land, and for a refused or failed one, a short explanation from Alpacon.

The reason labels are:

Label	What it means
Signature invalid	The release’s signature didn’t verify, so the agent didn’t install it
Digest mismatch	The downloaded package didn’t match its published checksum
Download failed	The agent couldn’t download the release
Swap failed	The agent couldn’t replace its own binary with the new one
Health check failed	The new version didn’t pass its health check after starting
Package manager error	The system package manager (`apt`/`yum`) reported an error
Maintenance window closed	The maintenance window closed before the upgrade could start
Alpacon configuration issue; no action needed	A problem on Alpacon’s side. Nothing needs changing on your server
Unknown error	The agent reported a failure without a known reason

A Refused row usually means the maintenance window closed before the upgrade reached the agent, the policy was switched to Manual, a manual upgrade replaced a pending automatic one, or Alpacon paused automatic upgrades platform-wide. Nothing was installed, and the agent keeps running the version it had.

Records begin when upgrade history was introduced. Earlier upgrades aren’t shown, and a server with no upgrades since then shows “Upgrade records are kept from the time this history was introduced. Earlier upgrades are not shown.” Each upgrade is also recorded in the activity log, both when it’s sent and when it ends, so it’s included when you search or export workspace activity.

To see upgrades across every server, use Recent agent upgrades under Agent updates in workspace settings, or the agent upgrades API.

Upgrade failure alert

When an agent upgrade fails or is rolled back, Alpacon raises a warning alert on that server, titled for example Agent upgrade to 1.5.0 failed. It appears in the bell and the alert list only: no email or Slack message goes out for it, and it isn’t part of the hourly open alert digest. A server has at most one of these alerts open at a time, however many upgrades fail in a row, and the next successful upgrade resolves it. A successful upgrade sends no notification, and an upgrade that fails because of Alpacon configuration issue; no action needed raises no alert.

Host operations

Rebooting a server, shutting it down, or upgrading its operating system packages isn’t a button on the server page. Run it inside a work session instead: open Websh in the session, or attach alpacon exec to it with --work-session, then run the command with sudo, the same way as any other privileged command (sudo reboot, sudo shutdown -h now, sudo apt upgrade -y or your platform’s package manager). For example, alpacon exec --work-session SESSION_ID my-server -- sudo reboot reboots my-server inside the session SESSION_ID. That keeps the operation under your workspace’s sudo policy, MFA, and approval rules, and Alpacon records the session like any other. If you’re planning one, mute the server’s alerts first—Alpacon doesn’t hold the offline alert automatically for a command run this way.

Server list actions

Select one or more servers on the server list to:

Request a work session covering the selected servers.
Mute alerts on the selected servers—see Mute a server.
Delete the selected servers—see Bulk deletion.

Agent restart and agent upgrade aren’t available from the list; use the Agent card on each server’s detail page. Refreshing system information isn’t available from the list either; use Refresh now next to the last-synced time on the detail page.