Automations

An automation is a piece of work you describe once and let CloudPeek run for you. It gathers evidence from your tools, follows the playbooks your team has written, and, when it wants to change something, stops and asks a person first.

Where Automatic Triage and Follow-up Actions are built-in behaviours that run against every incident, automations are the workflows you define: the recurring checks, the routine evidence gathering, and the standing responses your team would otherwise do by hand.

What an automation can do

What starts a run

Two separate questions decide when an automation runs: what kind of thing starts it, and whether it also runs on a clock.

What starts it is the workflow's source:

• On request, where a person or another part of CloudPeek hands it something to look into.
• Incident source, where new security findings arrive from your connected sources and each one starts its own run.

Timing is optional, and layered on top. A workflow can additionally run:

• On a schedule, as a five-field cron expression, evaluated in UTC.
• At an interval, entered in whole minutes, up to a maximum of thirty days apart.

Leave the timing unset and the workflow runs only when its source delivers something.

Four kinds of step

Every step belongs to one of four lanes, and the lane decides what that step is allowed to do. This is what keeps an automation from quietly changing your estate.

A run works through the lanes in that order: everything it reads, then anything it records, then the plan it proposes, then, only after a person has approved, the acting steps.

Follow your own playbooks

A step can hand an objective to an agent along with one of your playbooks, and the agent follows it and reports what it found. This is the usual way to build a step: the knowledge lives in the playbook your team already maintains, in the Wiki, rather than being duplicated into the automation.

Steps can also use CloudPeek's built-in capabilities directly, for work like pulling findings from a connected tool, removing duplicates, triaging what is left, running follow-up actions, or drawing the results together into an incident.

Pass results from one step to the next

Steps run in order, one after another, and each step can use the output of an earlier one. When you add a step, the builder offers the outputs available at that point rather than asking you to wire anything up by hand.

If a block of steps needs to repeat, a loop can run it between 2 and 100 times, stopping early when a condition you nominate is met.

Use your tools, without hard-coding them

An automation does not name a specific tool. It declares the capability it needs, and you bind that to one of your configured tools when you set it up. The same automation can therefore be pointed at different tools in different tenants, and rebinding it to a new tool does not mean rebuilding it.

Stop for approval before acting

This is the guardrail that matters most, and it is not optional:

When a run reaches its approval point it pauses and waits. A person reviews the proposed plan and approves or rejects it. Two rules apply:

• The person who produced the plan cannot approve it. Approval is a separate pair of eyes by design.
• Approvals expire. A plan left unapproved times out rather than sitting indefinitely, which stops a stale plan being waved through days later against an estate that has moved on.

Approving re-checks the tools the plan intends to use at the moment of approval, so access revoked since the plan was written causes the approval to fail rather than proceed.

This is the same model described in Human-in-the-Loop (HITL), applied to scheduled work.

Publish versions, so behaviour cannot drift

You edit an automation as a draft, and publish it when it is ready. Publishing freezes a version, including a snapshot of any playbook it uses. A run executes that snapshot, so editing the underlying wiki page later changes what future versions do, never what the published one does.

That property is what makes an automation safe to leave running: what it did last month is still recoverable, and it cannot silently change behaviour because somebody tidied up a playbook.

Building one

Automations live under Settings → Automations. Choose New to open the builder, which walks through five steps.

1. Name it

Give it a name that says what it does. This is what you will see in run history and in the incident view, so "Weekly external exposure check" beats "Automation 3".

2. What it does

Add your steps in the order they should run. For each one you pick what the step does, and, if it is a playbook step, which playbook the agent should follow. The builder labels each step with its lane, so you can see at a glance whether your workflow only reads or whether it intends to act.

Set what starts it here too, and its timing if it should also run on a clock.

3. What it may use

Bind each capability the workflow needs to one of your configured tools. Only tools you have already set up under Tools & Integrations are offered, so an automation cannot reach anything you have not connected.

4. Approvals

If any step acts, turn on Ask me before it changes anything and choose which step's plan gets approved. If your workflow only reads, you can leave this off.

5. Review

Check the whole workflow, then publish it. CloudPeek validates the workflow as you go rather than only at the end, so problems surface next to the step that caused them.

Once published, enable it and it will start running on its trigger.

Building your own workflows

The wizard gets a workflow running. This is how to design one that stays useful.

Start read-only, add acting later

Build the reading half first and let it run for a while. A workflow made only of Read steps cannot change anything, so the cost of getting it wrong is a wasted run and some output you ignore.

Once you trust what it finds, add the Plan and Act steps. You will be prompted for an approval at that point, because a workflow that acts cannot exist without one. Nothing about the reading half changes, so you keep the confidence you built up.

This ordering matters more than it sounds. The hard part of a workflow is almost never the acting step, it is being sure the evidence underneath it is right.

Put the knowledge in a playbook, not the workflow

A step that runs a playbook hands an agent an objective and lets it follow your team's written procedure. Prefer that over encoding the same judgement into the shape of the workflow.

The reason is maintenance. A playbook lives in the Wiki, is reviewed like any other page, and is improved by the people who actually do the work. A workflow that hard-codes the same reasoning across several steps has to be rebuilt every time the procedure changes, and tends to drift quietly out of date because nobody thinks of it as documentation.

Save steps you will use again

A step you have wired up can be saved as a step template, with a name and a note on when to reach for it. It then appears alongside the built-in steps next time you add one.

This is worth doing as soon as you write a second workflow that starts the same way. Most teams find a handful of openings recur, such as pulling this week's findings from a particular source or triaging against a house playbook, and templates keep those consistent instead of subtly different in each workflow.

Keep each workflow to one job

A workflow reads best when it answers one question. Several small workflows on their own schedules are easier to reason about, approve and turn off than one long chain that does the week's work in a single run.

They also fail better. A focused workflow that breaks stops one thing, and the run history tells you which. A workflow that does six unrelated jobs takes all six down and buries the cause.

Editing a workflow that is already running

Editing gives you a draft. The published version keeps running untouched while you work, so there is no window where a half-finished edit is live.

When the draft is ready, publish it. That creates a new version and moves the workflow onto it. Because publishing snapshots any playbooks the workflow uses, the version that ran last week still describes exactly what it did, even after you have changed both the workflow and the playbook.

If you need it to stop in the meantime, disable it. Disabling leaves the workflow and its history in place and simply stops new runs starting.

Check the run before you trust the workflow

After the first run, open it under Operations → Automations and read what each step actually produced, rather than only whether the run went green. A workflow can complete successfully while gathering the wrong evidence, and the run detail is where that shows up.

The step outputs are also the fastest way to see why a later step behaved oddly, since each step works from the output of the one before it.

Watching runs

Runs appear under Operations → Automations. Open one to see each step, what it produced, and the events along the way. Where an automation contributed to an incident, its activity is visible from the incident itself, so you can see what ran without leaving the investigation.

Limits

These bound every automation, and exist to stop a misconfigured workflow consuming an environment.

A step that fails is retried within its budget, backing off between attempts, and the run fails cleanly once the budget is exhausted rather than running indefinitely.

Related

• Human-in-the-Loop (HITL): the approval model automations use.
• Runbooks & Playbooks: writing the playbooks automation steps follow.
• Automatic Triage: the built-in pipeline that runs on every incident.
• Incident Management: where automation activity shows up on an incident.