Monitors
A monitor is a wait condition an operation arms to watch for one outside signal — an HTTP callback, a script's output, a new Cybergraph entity, a schedule, a child operation finishing, or a human reply. When that signal arrives, the monitor fires: it delivers the signal's payload back into the operation. "Fires" (or "fired") is just that moment — the thing the monitor was waiting for happened. A monitor that is still waiting hasn't fired yet.
Operations arm ordinary monitors themselves whenever they need a signal from outside their own actions — for example, a target calling back or a long job finishing. You don't set one up; you see it on the operation and can continue, cancel, or extend it (see Lifecycle & controls). Action and output-file approvals use their own approval controls instead.
At a glance
- What it is — A wait condition an operation arms to watch for one outside signal, then delivers back into the operation.
- When to use it — Whenever an operation needs something that happens outside its own actions: a callback proving a blind finding, a long job reporting in, or a human reply.
- Inputs — A signal source (see Signals) and a mode (Blocking or Background); ordinary monitors have an optional time limit (default 24 hours, extendable).
- Outputs — A state transition (Armed → Fired / Expired / Cancelled) and, on fire, the signal's payload delivered back into the operation.
- Related objects — Signals, Lifecycle & controls, Automations (realm-level monitors that start a new operation per fire).
- Common actions — For ordinary monitors, see Lifecycle & controls: Run in background, Continue, Cancel, Extend. Approval waits use their dedicated approval controls.
- API / tool links — See Signals — the webhook callback URL and Vessel token contracts are documented there.
Modes
| Mode | Effect |
|---|---|
| Blocking | The operation waits until the signal arrives or the monitor expires. Action and output-file approvals do not expire automatically. A waiting operation does no work and incurs no usage. |
| Background | The operation keeps working; the signal is delivered on its next step when it arrives. |
States
| State | Meaning |
|---|---|
| Armed | Watching; the signal hasn't arrived yet, so the monitor hasn't fired. |
| Fired | The watched signal arrived. The monitor delivers its payload into the operation, which resumes (Blocking) or receives it on its next step (Background). |
| Expired | The time limit passed with no signal; the operation resumes and is told the signal never came. |
| Cancelled | Dismissed by you or when the operation ends. |
Ordinary monitors have a time limit (default 24 hours, extendable from the console). Action and output-file approval waits are separate and do not expire automatically. Resolve them with their dedicated approval controls, send a new instruction that supersedes them, or switch directly to Auto. Switching from Manual to Semi-Auto re-evaluates the action under the Semi-Auto policy and can ask for approval again.
Monitors vs. automations
A monitor resumes its own operation. An automation is a realm-level monitor that starts a new operation every time it fires — used for scheduled (CRON) and inbound-webhook runs.
Next steps
- Signals — the six sources a monitor can watch and how each fires.
- Lifecycle & controls — manage a monitor or waiting operation from the console.
- Automations — realm-level monitors that spawn a new operation per fire.