Signals

Every monitor watches a single signal source. That source is what makes the monitor fire, and its mode determines what happens when it does.

At a glance

• What it is — The six signal sources a monitor can watch, and how each one fires.
• When to use it — Choosing which source to arm for a given wait condition; see the source-to-use-case table below (webhook, vessel, Cybergraph, operation, schedule, input).
• Inputs — Source-specific: a callback URL plus optional secret (Webhook), a token printed by a script (Vessel), entity types/actions/filters/cooldown (Cybergraph), a child operation (Operation), a CRON schedule (Schedule), an approval or form (Input).
• Outputs — The fired signal's payload delivered back into the operation: request method/headers, the decoded script payload, the matched entity, the child operation's result, or the form response.
• Related objects — Monitors (modes and states), Lifecycle & controls, Automations (Schedule signal as a realm-level monitor), Cybergraph, Vessels.
• Common actions — See Lifecycle & controls for managing an armed or fired monitor.
• API / tool links — Webhook callback contract documented under Webhook (X-Monitor-Secret header); Vessel token/payload contract documented under Vessel.

Source	Fires when	Used for
Webhook	An HTTP request hits the monitor's callback URL	Out-of-band callbacks, third-party webhooks
Vessel	A script prints the monitor's token to a Vessel's output	Catching a result mid-run from a long command
Cybergraph	A matching entity is added or changed in the graph	Reacting to new hosts, domains, or findings
Operation	A child operation finishes	Fan-out / fan-in across sub-operations
Schedule	A recurring time arrives	Scheduled runs (automations)
Input	You approve, deny, or submit a form	Approvals and human-in-the-loop steps

Webhook

Cracken gives the monitor a unique callback URL. Any GET or POST to it fires the monitor; the request's method, source IP, and headers come back as the result. Attach a secret to restrict who can fire it — the caller sends it in the X-Monitor-Secret header:

curl -X POST "<callback-url>" \
  -H "X-Monitor-Secret: <secret>" \
  -d '{"hit": "10.0.0.5"}'

Vessel

When a script needs to hand a result back mid-run, the monitor gives it a token. The script prints the token immediately followed by a base64 payload on its own line; Cracken catches it and fires the monitor with the decoded payload:

printf '%s%s\n' "<token>" "$(printf '%s' '{"hit":"10.0.0.5"}' | base64)"

The token is unique per monitor, so unrelated output never fires it by mistake.

Cybergraph

Fires when an entity in the Cybergraph is created, updated, or deleted matching a condition — entity types (e.g. IPAddress, Vulnerability), actions, optional property filters, and a cooldown between fires. Usually background, so an operation reacts as the graph grows.

Operation

How an operation waits on a child it spawned. Blocking pauses the parent until the child finishes; Background lets it keep working and notifies it on completion.

Schedule

A recurring (CRON) trigger. As a realm-level automation, each fire starts a new operation.

Input

Approvals and forms. When an operation needs you to approve, deny, or fill something in, it pauses on an input monitor; your reply fires it and flows into the operation.

Next steps

• Monitors — modes, states, and how monitors differ from automations.
• Lifecycle & controls — manage an armed or paused monitor from the console.
• Automations — realm-level monitors that start a new operation on each fire.