Automations

Automations create operations automatically — on a recurring schedule, in response to an inbound HTTP call, or when matching Cybergraph activity appears. Define an automation, provide a task description, optionally select a playbook, and Cracken creates the operation each time the automation fires.

At a glance

What it is — A realm-level monitor that creates a new operation automatically when its source (schedule, webhook, or Cybergraph match) fires.
When to use it — Recurring scheduled assessments; integrating external systems (CI, SIEM/SOAR, ticketing) via HTTP callback; auto-starting an operation when a Cybergraph entity changes.
Inputs — Name, operation task, optional playbook, plus source-specific fields: CRON expression + timezone (Scheduled), optional header secret (Webhook), entity types + actions + optional property filters + cooldown (Cybergraph).
Outputs — One operation per fire (linked back via monitor_uuid), run history, and execution stats (last fired, total fires).
Related objects — Operations, Cybergraph, Realms, Playbooks, Monitors.
Common actions — Create Automation, Edit, Rotate URL (webhook only), Delete.
API / tool links — Webhook callback contract: see Invoking the webhook.

What are automations?

An automation is a realm-level monitor that creates a new operation when its source fires. Three source types are supported:

Scheduled automations — execute on a recurring schedule defined by a CRON expression and timezone
Webhook automations — execute when an external system makes an HTTP call to a unique, unguessable URL (optionally protected by a header secret)
Cybergraph automations — execute when matching graph entities are created, updated, or deleted

Every automation has a name, an operation task (labeled Operation Instructions in the form, operation_task in API payloads — the task text assigned to each created operation), and an optional playbook to guide the assessment methodology. Each source type adds its own required fields:

Source	Required fields	Fires when
Scheduled	CRON expression, timezone	The schedule's next time arrives
Webhook	none (URL and token are generated) — an optional header secret restricts callers	An HTTP request hits the automation's URL
Cybergraph	entity types, actions (`create`/`update`/`delete`)	A matching entity is created, updated, or deleted

Without a header secret, a webhook automation is token-only: the unguessable URL token is the only credential. Configure a header secret so that possession of the URL alone is not enough to start an operation.

Lifecycle

An automation has three states — Active, Paused, and Cancelled:

State	Meaning
Active	Armed and watching its source; fires and creates an operation each time the source matches.
Paused	Retained but not firing. A paused scheduled automation keeps its configuration and accepts no new fires until you resume it. Set with Pause; reverse with Resume.
Cancelled	Terminal. Set by Delete; the automation stops firing and any webhook URL stops responding immediately.

To stop a scheduled automation without losing it, use Pause, then Resume when you want it firing again. A webhook automation only fires when its URL is called, so you can also stop it by pausing the caller — or use Rotate URL to cut off the current URL while keeping the automation. See Managing automations.

Creating a scheduled automation

Step-by-step instructions

Navigate to Automations within your realm
Click Create Automation and choose Scheduled from the dropdown
Provide a name for the automation
Under Schedule, pick a cadence tab (Minutes / Hourly / Daily / Weekly / Monthly / Advanced) and set the cadence fields — for example, on Monthly set the Day of Month and At Time. Confirm the generated CRON expression and preview (e.g. 0 9 5 * * → "At 09:00 AM, on day 5 of the month") read as valid, and check the Next runs list. Advanced users can enter a raw CRON expression on the Advanced tab instead. The timezone defaults to UTC.
Enter the Operation Instructions — the task description for each created operation (Markdown is supported)
Optionally select a playbook to define the assessment methodology, or leave No playbook
Save the automation

The automation opens with Settings and Run History tabs; runs populate Run History once the trigger fires, and the automation begins executing on the next scheduled time after creation.

Webhook automations

Webhook automations create an operation in response to an HTTP request — useful for integrating Cracken with CI pipelines, SIEM/SOAR platforms, ticketing systems, or any external system capable of making an HTTP call.

Creating a webhook automation

Navigate to Automations within your realm
Click Create Automation and choose Webhook from the dropdown
Provide a name
Optionally provide default Operation Instructions — used when an incoming request does not supply one
Optionally select a playbook
Save the automation

On creation, Cracken returns the automation record, including a unique webhook URL under Cracken's monitor callback path.

If you set a header secret when creating or updating the automation, external callers must send that raw value in the X-Monitor-Secret header. Cracken stores the secret as an encrypted realm secret and adds it to the realm's Realm Secrets list with a reference such as {{secret:webhook_<id>.secret}}, which you can use in operation tasks. Set a header secret on every webhook automation you expose to an external system — it is the credential that still protects the automation if the URL is logged by a proxy, forwarded in a ticket, or pasted into a shared config. Leaving the field blank keeps the webhook token-only: the URL token alone authorizes the call, and no realm-secret reference is created.

Automations created by an agent or tool can request a generated header secret for internal execution; in that case the secret reference is returned directly in the tool result.

Invoking the webhook

Send a POST request to the webhook URL returned at creation. If the automation has a header secret, include the raw value you set in X-Monitor-Secret. Use the exact URL Cracken returned when you created the automation, not a hardcoded prefix.

POST <webhook-url-returned-at-creation>
X-Monitor-Secret: <secret>
Content-Type: application/json

{"operation_task": "investigate suspicious login from 203.0.113.5"}

Body:

The body is optional. Malformed JSON, non-object JSON, blank fields, and unrelated fields are still captured as callback evidence but are ignored for overrides.
Only non-empty string operation_task and operation_name fields change behavior.
If the body is omitted or empty, the automation's default operation_task is used.
If neither the body nor the automation provides an operation_task, the request is rejected with 400.
operation_name is optional and only allowed when the automation has a header secret (has_secret=true). When provided, it must be a non-empty string and becomes the operation name for that invocation; when omitted, Cracken generates the name normally.
Sending operation_name to a token-only automation (has_secret=false) is rejected with 403. Token-only callbacks may still override operation_task.
If the webhook secret was explicitly cleared in automation settings, omit the X-Monitor-Secret header. The URL token alone authorizes the callback in that state.

Responses:

Status	Meaning
`202 Accepted`	Callback accepted — body contains `monitor_uuid` and `event_uuid`
`400 Bad Request`	Invalid `Content-Length`, or no `operation_task` in either the body or automation
`403 Forbidden`	Known automation with a missing or invalid secret while `has_secret=true`, or an `operation_name` override sent to a token-only automation (`has_secret=false`)
`404 Not Found`	Unknown, cancelled, expired, already-fired, or non-webhook automation
`413 Payload Too Large`	Request body exceeds the configured limit
`500 Internal Error`	Operation creation failed

Security and URL rotation

Supplied header secrets are verified in constant time for inbound callbacks and are also stored as encrypted realm secrets for execution-time secret references.
UI/API webhook automations created without a header secret are token-only (has_secret=false). Invalid or missing secrets return 403 only when has_secret=true.
Replacing the header secret updates the encrypted realm secret. Clearing it sets has_secret=false; callbacks then do not require X-Monitor-Secret, so only clear it when the URL token is sufficient for the integration.
The raw header secret cannot be retrieved after it is saved, and generated internal values are never exposed.
Replace the header secret in the automation editor.
Use Rotate URL to issue a new callback URL token. The previous URL stops working immediately, but the existing header secret remains valid for the new URL.

Behavior

Each successful request creates exactly one operation. Cracken does not deduplicate callbacks, so repeated calls for the same event create separate operations — track which events you have already sent and suppress repeats on your side.
Throttle the calling system to the cadence you actually intend to run. Cracken creates one operation per accepted call, so a tight loop or a fan-out on the caller's side produces operations you did not intend.
Cracken does not retry on failure; if a request returns 5xx, the caller must retry. Use bounded retries with backoff so that a transient failure does not become a burst of duplicate operations.
Each created operation links back to its automation through monitor_uuid.

Cybergraph automations

Cybergraph automations create an operation when graph activity matches the configured condition. Use them for workflows such as starting an investigation when a new Finding, Device, Service, or Vulnerability node appears. Entity types use the Cybergraph's canonical node labels (for example IPAddress, Port, Domain, Credential) and are validated on save.

Creating a Cybergraph automation

Navigate to Automations within your realm
Click Create Automation and choose Cybergraph from the dropdown
Provide a name
Enter self-contained Operation Instructions
Select one or more entity types
Select one or more actions: create, update, or delete
Optionally add exact-match property filters
Optionally set a cooldown to suppress repeated starts
Optionally select a playbook
Save the automation

The realm must have Cybergraph access. Each matching event starts a new operation with the configured task and playbook.

Operation tasks can include monitor event variables — {{entity_type}}, {{entity_name}}, {{action}}, and {{properties}} — so each spawned operation knows what changed.

CRON-based scheduling

Schedules use standard cron expressions to define when operations are created:

Expression	Schedule
`0 0 * * 1`	Every Monday at midnight in the automation timezone
`0 9 * * *`	Every day at 9:00 AM in the automation timezone
`0 0 1 * *`	First day of every month in the automation timezone
`0 0 * * 1-5`	Every weekday at midnight in the automation timezone

CRON fields are interpreted in the automation's configured IANA timezone, which defaults to UTC when none is set. Each automation creates one operation per execution.

After each run, Cracken recalculates the next scheduled time, so an automation never fires twice for the same slot.

Managing automations

From the automations list:

Edit — modify the name, schedule (CRON only), task, or playbook
Pause / Resume — scheduled automations only; Pause retains the automation without firing, Resume re-arms it
Rotate URL — webhook automations only; issues a new callback URL token and invalidates the previous URL
Delete — cancel the automation

Deleting an automation marks it cancelled, removes any webhook URL token index, and prevents future executions. Cancelled automations are removed from the list. Cancelled webhook URLs stop responding immediately.

Viewing automation runs

Each automation tracks the operations it has created. View the history to see:

When each operation was created
The current status of each created operation
Links to the full operation view

Execution statistics

Each automation tracks:

Last fired — when it most recently created an operation
Total fires — how many operations it has created

Both update after each successful run.

How the scheduler works

The Cracken scheduler checks for due automations about once a minute and creates one operation for each automation whose scheduled time has arrived. It guarantees each automation fires exactly once per scheduled time, even when multiple scheduler instances run concurrently.

Next steps

Operations — the operation each automation creates.
Cybergraph — the graph that drives Cybergraph automations.
Realms — the boundary automations belong to.

At a glance​

What are automations?​

Lifecycle​

Creating a scheduled automation​

Webhook automations​

Creating a webhook automation​

Invoking the webhook​

Security and URL rotation​

Behavior​

Cybergraph automations​

Creating a Cybergraph automation​

CRON-based scheduling​

Managing automations​

Viewing automation runs​

Execution statistics​

How the scheduler works​

Next steps​