Act
Verification
Verification is the check that an action worked: MonitOps compares fresh telemetry with the action's recovery criteria after the run. A successful command is not a recovered service, so an incident resolves only when the criteria are met.
How it works#
Recovery criteria#
Each action in the catalogue declares what recovery looks like. A criterion can take one of these forms.
| Form | Example |
|---|---|
| A check passes over a window | The synthetic checkout check passes on every run in 5 minutes |
| A signal is back within its expected range | The error rate of order-api is back within its baseline |
| A health state | A system reports healthy |
A criterion names a signal in the catalogue (see Signal catalogue) and what must be true of it.
Fresh telemetry, not the command result#
After a run, MonitOps evaluates the criteria on telemetry that arrives after the run. The response of the command to the automation platform does not count: a call that succeeded can leave the fault in place, and a call that failed to return can have worked.
The outcome#
| Outcome | Result |
|---|---|
| Verified | Every criterion is met. The incident resolves |
| Not confirmed | At least one criterion is not met. The incident stays open and says which one |
Uncertain outcomes#
If the outcome of a run is uncertain, for example because the call did not return, MonitOps reconciles it before anything is retried. The action carries a stable operation identity, and the result is read back from the system. The action is never repeated on the assumption that the first attempt failed.
What resolves an incident#
An incident resolves when its alerts have cleared or, after an action, when recovery is verified. Alert recovery has its own rules: a numeric alert clears after consecutive evaluations meet the recovery threshold, and a check recovers after consecutive successful runs. Missing data never counts toward recovery.
What you see in the console#
The verification panel shows each criterion with its current reading and whether it is met. After the run for INC-20931, run RUN-5521 shows 20 / 20 checks passed over 5 minutes, the error rate of order-api back in baseline, and the incident Resolved, with the audit line for the approver.
Recovery verification
Recovery verified against fresh checks, not the command result.
14:09:52 ICT · run RUN-5521 · approved by Ploy K.
The run history shows the verification result for every run.
Limits and defaults#
- Verification runs against the criteria the catalogue entry declares.
- An unverified run leaves the incident open.
Failure states#
| State | What happens |
|---|---|
| Criteria not met | The incident stays open and says why |
| Uncertain run outcome | Reconciled before any retry |
Related#
Last updated October 2026