Act
Actions and approvals
An action is a catalogued recovery procedure, and a run is one approved execution of it. Actions come from a catalogue your team maintains, run within the authority your policy defines, and resolve an incident only when recovery is verified.
MonitOps is useful before any write access is granted. Detection, correlation, explanation and the copilot work with read access, and actions stay unavailable until you grant write access.
How it works#
Catalogue#
Each catalogue entry declares:
| Field | Meaning |
|---|---|
| Services | The services the action may touch |
| Changes | What the action changes |
| Expected impact | What the operator should expect when it runs |
| Rollback | How to undo it |
| Recovery criteria | The signals that must recover for the action to count as successful |
| Endpoint | The allowlisted endpoint on your automation platform that the action calls |
Actions execute only through allowlisted endpoints on your automation platform, using scoped credentials. Nothing outside the catalogue can run.
Policy#
Policy decides who may request an action and who must approve it, and when an action may run. Approval is a single level. The requester cannot approve their own request.
Recommendation#
On an incident, MonitOps may recommend an action from the catalogue with its rationale. The recommendation is proposed by the AI; the catalogue, the role and the approval are checked in code. The model does not approve and does not run anything.
Flow#
| State | Meaning |
|---|---|
| Requested | An operator requests the recommended action |
| Approved | An approver approves it; a different person from the requester |
| Running | The action calls its endpoint and the run is recorded |
| Verified | Fresh probes and metrics meet the recovery criteria and the incident resolves |
| Not confirmed | Recovery criteria are not met; the incident stays open and says why |
Verification#
A successful command is not a recovered service. After a run, MonitOps checks fresh synthetic probes, error rates and latency against the action's recovery criteria. The incident resolves only when those criteria are met.
Uncertain outcomes#
If the outcome of a run is uncertain, for example the call did not return, MonitOps reconciles it before anything is retried. It does not repeat an action whose first attempt may have succeeded.
Procedure#
- Open the incident and read the recommended action and its rationale.
- Request the action. This needs the operator role.
- A person with the approver role other than the requester approves or rejects it in the approval dialog.
- Watch the run. The incident timeline records the request, the approval, the run and the verification.
- Read the verification panel. If it is not confirmed, the incident stays open; open the run to see which criteria were not met.
What you see in the console#
The run history lists every run with requester, approver, timing, outcome and verification result. The verification panel shows each recovery criterion with its current reading.
Recovery not confirmed
Recovery could not be confirmed against fresh checks. The incident stays open and says why.
Synthetic checkout probes did not meet the recovery criteria
Limits and defaults#
- Approval is single-level, and the requester cannot approve their own request.
- Each action can touch only the services it declares.
- Write access is off until you grant it.
Failure states#
| State | What happens |
|---|---|
| Recovery not confirmed | The incident stays open and says why |
| Uncertain run outcome | Reconciled before any retry |
| Approval by the requester | Refused |
| Endpoint outside the allowlist | The action cannot run |
Related#
Last updated October 2026