Approvers now see more than who submitted a request. The approval card shows which channel the request came through, and whether the platform verified the requester type or relied on the requester's own declaration. Before a request runs, approvers see the declared requester type and whether it was verified.
You also control which notifications are sent. During planned work, mute notifications for a server, turn off alerts for one event without affecting the others, and replay a rule over recent data before saving it. Extending a work session now requires a written reason for the approver to review.
Approval cards show the request channel and verification status
Approvers now see whether a request is marked as coming from an AI agent or a person, and whether that mark was verified, before making a decision. Commands and work sessions record the channel each request came through: web, CLI, MCP, API token or service token. The approval card shows the channel instead of leaving the field blank.
The requester tag also indicates whether the requester type was verified. A request marked as coming from an AI agent is either verified by the server from the credential it issued, or declared by the requester itself, and not verified. CLI requests are always marked unverified, because a person at a terminal and an agent driving the CLI present the same credential.
The tag appears on approval cards in Execution > Pending approvals, in Live activity, and on session pages. Session pages also show the request channel.
Mute a server during planned work, and tune alerts by event
If you expect alerts while working on a server, you can temporarily mute notifications for that server. The alerts are still recorded. Choose 1 hour, 4 hours, or a custom end time, up to 7 days. Use Mute alerts on the server page, or select multiple servers from the server list. When the mute period ends, any unresolved alert is sent once.
Notification preferences now offer finer controls than the category-level settings introduced in August. You can enable or disable notifications by severity and by individual event. Turning off threshold alert emails does not affect offline alerts.
In the Metrics app, each alert rule now has a details page listing the servers it applies to. Before saving a rule, you can replay it over recent data to see how often it would have fired. You can also set the severity for each rule, and critical alerts continue to be sent by email. Alert history shows why an alert was resolved, which channels received it, and whether delivery succeeded on each channel, so a missed alert can be traced to the delivery that failed.
Server alert muting is available on all plans. The notifications it holds, alert rules and alert history are Essentials or higher.
Session extensions require a reason, and approvers set the end time
The time an approver granted now stays the limit. Extending a session requires a written reason, and you request it from the session page. Whether it needs approval follows the same rule as requesting a new session: if your workspace auto-approves the session, the new end time applies immediately; otherwise the request goes to an approver, who reviews the reason and can approve a shorter extension than requested, but never a longer one. Either way, the reason stays on record.
Also shipped
- When a request is denied, the console and CLI show which role or token scope caused the denial and which permissions were missing.
- The activity log now shows the previous value before a change. Essentials or higher.
- When a server is reassigned, its visibility updates immediately for both the new and previous owner.
- Each workspace can choose automatic or manual agent updates. Automatic updates run only during the configured maintenance window, and each server shows its upgrade history.
- Server reboots, shutdowns and OS upgrades now run as commands inside a work session. The same sudo policy, MFA, approval and recording apply as for any other command. See Behavior changes for details.
- Controls for restarting and upgrading the agent itself have moved to the agent section of the server page.
- During planned maintenance, the console shows a banner and holds offline alerts, then sends them as one message.
alpacon apilets you send API requests using your existing CLI login, and the CLI now follows the system proxy settings.- Alpamon detects a lost connection within 45 seconds and reconnects.
- This release includes security improvements. We recommend updating self-hosted deployments.
Behavior changes
Reboot, shutdown, OS upgrade and agent shutdown actions have been removed from the console, API, Alpacon CLI and Alpacon MCP. Scripts that call them now fail. Run the host's own command inside a work session instead: alpacon exec <server> -- sudo reboot for a reboot, sudo shutdown for a shutdown, or your OS upgrade command for an upgrade. Agent shutdown is removed; restarting and upgrading the agent remain in the agent section of the server page. alpacon agent restart and alpacon agent upgrade now ask for confirmation, so scripts need -y. A reboot run this way does not mute alerts on its own, so set Mute alerts first.
Metric alerts with warning severity are no longer sent by email. To keep receiving emails, set the rule's severity to critical. New workspaces start with the Metrics extension disabled. You can enable it under Workspace settings > Integrations > Extensions.
API tokens without any user, group, membership or application scope are now refused on identity endpoints. Check the tokens your integrations use.
Only a Superuser can delete a workspace. Deleting a workspace removes Alpamon from every connected server. This cannot be undone.
