Workflows
The products, wired together
Automate what people already do by hand.
Draw a graph of reads, checks, approvals and actions, and run it on a schedule, an event, a webhook or a button. Each workflow runs as its own credential, so it never reaches further than the person who wrote it.
- Node types
- 40+
- Templates
- 109
- Triggers
- schedule · event · webhook
- After a crash
- resumes
How it works
From a sentence or a template to a run you can read.
Start from a template or a sentence
Pick one of 109 templates across monitoring, incidents, databases, Kubernetes, storage, CI/CD and security — or describe it and Runa draws the graph on the canvas, checked by the same validator as a save.
Wire the steps
Reads, conditions, approvals, actions and notifications, each with its own retries and hard time limit. Secrets are referenced by name and masked in every trace.
Disk on {{ nodes.disk.host }} is at {{ nodes.disk.percent }}%. Token: {{ secret "pagerduty" }}
Choose what starts it
A button, a schedule in a real timezone, a webhook URL, or an event — an alert firing or resolving, an incident declared, a detection raised, a task failing, or an object landing in a bucket.
What makes it safe to leave running
Automation that answers to the same rules as people.
Its own credential
Every workflow is bound to an agent access. What it may do is that access intersected with its author’s current permissions.
Human approval
A manual.approval step pauses the run until someone approves or rejects. Whole-plan approval is tied to a hash of the graph, so any edit asks again.
Resume, don’t repeat
Runs are leased, and a run whose worker died is picked up again. Succeeded steps are reloaded, and a command already sent is adopted, not re-sent.
Guardrails on commands
Shell steps on servers go through guardrails, and a server that requires approval needs an active just-in-time grant.
Destructive steps are declared
A step marked destructive must have no retries, a blast-radius note and an approval before it — or the workflow does not save.
Connections, not pasted keys
PagerDuty, Jira and GitHub actions, email through your own provider, and Slack, Teams, Discord, Mattermost or a signed webhook.
Sub-workflows and loops
Call another workflow up to five levels deep, or run one per item for up to fifty items with a concurrency cap.
Runs you can read
Every run keeps its trigger, each step’s inputs and outputs and any linked task, live while it runs. Kept for 30 days.
Schedules that survive DST
Real IANA timezones, a preview of the next run, and one make-up run after downtime instead of a backlog.
Nodes
Everything you can put on the canvas.
Palette groups as they appear in the editor. Colour on the canvas carries the family; the stripe down a node’s edge says it changes something or waits for a person.
| Start | trigger — manual, schedule, once, event; plus a webhook on any of them |
| Read | db.query · kube.get · kube.logs · app.get · docker.logs · host.metrics · host.file_read · rollout.status |
| Workspace | incident.list · alert.list · detection.list · task.list · activity.search · incident.declare · incident.update · incident.note · alert.resolve |
| Decide | condition · switch · transform · assert |
| Act | task · server.exec · schedule.create · host.file_write · cloud.provision |
| Storage | objects.buckets · objects.list · objects.stat · objects.read · objects.write · objects.delete · objects.share · objects.presign_upload |
| Think | ai.agent — tool-using AI step, limited to what the workflow’s credential allows |
| Tell | notify · email.send · http.request · connector.call (PagerDuty, Jira, GitHub) |
| Flow | manual.approval · delay · sub.workflow · foreach |
Limits
What each plan includes.
| Plan | Free | Pro | Team | Enterprise |
|---|---|---|---|---|
| Workflows | 1 | 20 | 200 | 2,000 |
| Scheduled tasks | 1 | 20 | 200 | 2,000 |
| Agent accesses | — | 2 | 10 | 100 |
The plan counts saved workflows, not runs — runs are not metered. A graph can hold up to 200 nodes. The whole price list.
Questions
Before you let it run at night.
Can a workflow do something its author cannot?
No. It runs as an agent access intersected with the author’s current permissions — demote the author and the workflow loses the access with them.
What happens if a worker dies mid-run?
Another worker picks the run up. Steps that already succeeded are not run again, and a server command or task that was already sent is adopted rather than sent twice.
How is a webhook authenticated?
By the random token in its URL — anyone holding the URL can start a run, so treat it as a secret. It can be rotated or removed at any time.
Does a template arrive switched on?
A template opens in the editor with its graph filled in, and nothing is saved until you save it. Targets it needs are flagged for you to choose.
The rest of the workspace
Same bill, same credentials, same audit log.
Automate the runbook you keep doing by hand.
Start from a template, or describe it and let Runa draw it. Nothing runs until you save it.