Commands
Every command sent to a registered server through Alpacon — including the ones the Alpamon agent runs automatically — leaves a record here. Use this page to confirm a command ran, see who triggered it, and read what came back.
How to get here
Open the sidebar and go to Audit → Events → Commands (or My events → Commands if you’re a regular user).
What’s in the list
| Column | What it shows |
|---|---|
| Channel | How the command reached the server: a link to its work session, or the name of the service or API token that submitted it. Shows — when the command came through neither. |
| Server | The server the command targeted |
| Line | The command line that was executed. Shortened to fit the column—open the row for the full text |
| Result | The beginning of the output or return message, or — when there was none |
| Ran as | The system account the command ran as, with its group on a second line when the group differs from the account |
| Operator | The user, application, or token that submitted the command |
| Status | Where the command is now—see What the statuses mean |
| Risk level | The risk band assigned to the command: Info, Low risk, Medium risk, High risk, or Critical risk. Shows — when no band was assigned |
| Timing | Seconds the command waited before the server picked it up. Hover the value to see that delay and the elapsed run time together |
| Date | When the command was submitted. The only sortable column—click the header to switch between newest and oldest first |
Two columns are context-dependent: Channel is hidden when you are already looking at a single work session’s commands, and Server is hidden when you open the list from one server’s page.
Click any row to open Command details, which adds the full command line, the complete result with its exit code, and a Delivery breakdown of when the command was added, scheduled, delivered, acknowledged, and handled.
Use the search box to match on server, line, or operator.
What the statuses mean
A command is verified, then delivered, then run, and the Status column names the furthest point it has reached.
Before delivery
- Verifying: the command’s signature is being verified.
- Awaiting approval: the command is waiting for a person to approve it before it can be delivered.
- Rejected: signature verification refused the command.
- Denied: an ACL policy denied the command. This replaces whatever else the status would have been, and Command details shows a Denial reason.
On the way to the server
- Scheduled: the command is waiting for the time it was scheduled for.
- Queued: the command is ready to be delivered.
- Delivered: the command has been sent to the server.
- Running: the server is executing the command now.
Finished
- Success: the command completed successfully. The Result column shows the output.
- Failed: the command completed with an error. The Result column shows the error message.
Needs a look
- Stuck: no response for over 10 minutes.
- Error: an unexpected state—delivery was never confirmed either way.
A command that can still be called off shows a cancel action next to its status.
Verification status
Open a command to see its Verification—how the command was admitted before it ran. This is a separate question from the Status column, which is about what happened once it did run.
| Verification | Meaning |
|---|---|
| Pending | Still being judged. The command hasn’t been delivered yet. |
| Approved | Judged and cleared to run. |
| Rejected | The judgment refused the command. If the row nonetheless shows output, it carries the note Rejected by verification, but executed. |
| Skipped | Not judged—for example an agent task, which isn’t user-submitted. |
| Advisory | Ran without being gated, because the workspace’s execution control is set to Advisory. The judgment is recorded afterwards, and it changes nothing about the command that already ran. |
An Advisory row carries the note Judged after execution, not gated under the tag, so it isn’t mistaken for an approval. The judgment lands a moment after the command, and the row then shows its Risk score and Analyzed at. If the judgment can’t be produced at all, the row stays Advisory with those two fields empty, which is an honest record that nothing was ever assessed. Rejected at never appears on an advisory command, because nothing was refused.
Use the Verification filter to narrow the list to one value—filtering on Advisory answers “which commands ran without being gated?” in one query.
Who sees what
The page is open to all users, but the rows scope to your role.
Regular users see only the commands they themselves issued. The sidebar label is My commands.
Administrators see every command across the workspace. The sidebar label is Commands.
The narrowing is enforced server-side — direct URLs follow the same rule.
Common things you’d check here
- Operations: confirm a scheduled command actually ran. Track automated agent tasks and deployment commands.
- Debugging: open a failed command to read the error message and trace what went wrong.
- Security: review privileged or unusual commands. Spot commands no one should have submitted.
- Personal review: look up your own past commands to recover an answer or copy the line.