Skip to content

Remediation & Pending Actions

Guardian can take corrective action on an agent automatically or with your approval — for example, restarting a stuck service or freeing up disk space. Every action is risk-tiered, and anything above the lowest tier waits for a human to approve it.

Tier Label Behavior
1 Safe Executes automatically, no approval needed
2 Moderate Queued in Pending Actions until approved
3 High Risk Queued until approved, and requires typing the exact target hostname to confirm

Restart agent restarts the Guardian agent on a device, for example when it is using more memory than expected. A Technician or above requests it from the device’s Agent health panel; the device must be online. Because a person asked for it by name, the request is its own approval: it runs straight away and does not wait in Pending Actions. It is recorded in the Audit Log and in the action history. The agent stops cleanly and its service manager starts it again within a few seconds. It restarts only Guardian’s own agent, never the machine.

The Action Queue shows actions waiting on a decision, filterable by Awaiting Approval, Queued, Successfully Executed, Failed, or All History. Each entry shows its risk tier, title, description, target host, what triggered it, and how long until it expires.

  • Approve queues the action for execution. Tier 3 actions open a confirmation dialog where you must type the target machine’s hostname exactly before the button unlocks.
  • Dismiss cancels the action without running it.
  • Executed and failed actions show a result log with the command’s output.

Approving or dismissing requires the matching permission (approve_actions, approve_high_risk for Tier 3, or dismiss_actions) — Superadmins can always do all three.

The Remediation Log is a read-only audit trail of every automated action the self-healing engine has actually taken — what triggered it, which host it ran on, its severity, and the action taken. You can search by host or action, and export the full log to CSV.

Actions can originate from alerts crossing a threshold or from a Scheduler job. Successful and failed runs are also reflected back into the affected incident, if one exists.