Runbooks that run themselves, and tell you when they didn’t.
Health checks, onboarding, ticket routing and alert handling as workflows you can read, with an ops center that separates “not running” from “broken”.
Three workflows teams build here first.
- 01
Scheduled health checks that page the right person and open a ticket only when the retry also fails.
- 02
Joiner, mover, leaver flows across identity, chat, ticketing and cloud accounts.
- 03
Alert enrichment: pull the log line, the owner and the last deploy before a human ever reads the page.
What runs, step by step.
A scheduled check: read the metric, compare it to your threshold, then page, ticket and post only when it is over the line.
- 01Every few minutes
- 02Read service metrics
- 03Over threshold?
- 04Page on-call
- 05Open ticket
- 06Post to ops channel
Every step is a node type in the catalog. Diagram only: no data, no live run.
Before you start
- An AWS connection that can read CloudWatch metrics (or the Azure or Google Cloud equivalent).
- A PagerDuty service to open incidents on and a Jira project to open tickets in.
- A Slack channel the workflow can post to.
- The thresholds that count as unhealthy, written as branch conditions.
What you get
A check that runs on its own schedule, pages and tickets only when the metric is over the line, and shows up in the ops center with its status and health kept apart.
Limitations
- A schedule polls: a spike that starts and ends between two runs is not seen. For immediate alerts, start the workflow from your monitoring tool’s webhook instead.
- The CloudWatch nodes read and write metrics. Log queries go through the HTTP node with an AWS credential.
- The PagerDuty nodes cover incidents, on-call and services. Other PagerDuty endpoints go through the HTTP node.
- Auto Fix repairs only what it safely can; the rest stays in Workflow Health for a person to fix.
Scheduled health check with email alert
Ping an endpoint every 5 minutes; if it does not return 200, email the on-call address with the status code.
See each step's output, and approve the risky ones.
Illustrated with a support workflow; the run view and the approval request look the same for every workflow.
Built for this, not adapted to it.
84 trigger types
Schedules, webhooks, queues, mailboxes and app events, so a runbook starts from whatever already happens in your stack.
Cloud services as nodes
394 AWS, 182 Azure and 152 Google Cloud services are in the catalog as typed nodes with the provider’s own auth. No SDK glue.
HTTP node with cURL import
Paste the cURL from a vendor’s docs and get a configured request node. A service with an HTTP API is reachable without waiting for a typed node.
Error workflows and retries
Per-step retries and timeouts, and a separate error workflow that runs when the main one fails, so the failure itself is handled by a workflow.
Workflow Health before the first run
Missing connections, unreachable hosts and bad expressions are caught by a health pass before the schedule fires, and Auto Fix repairs what it safely can.
An ops center, not a list
Status and health are separate columns. An attention tab shows what needs a human now; the failure drawer shows the run, the step and the payload.
Start from one of these.
Each one imports into a workspace; swap the connections and run it.
- Scheduled health check with email alertPing an endpoint every 5 minutes; if it does not return 200, email the on-call address with the status code.
- Validated webhook to databaseAccept events by webhook, reject malformed payloads with a JSON schema, and upsert the valid ones into a SQL table.
- Scheduled API digest by emailEvery weekday morning pull a JSON summary from your API, have an LLM turn it into three bullet points and email the team.
Apps this kind of workflow usually touches.
Each one has its own page with operations, triggers and auth.
PagerDuty
Jira
Slack
Amazon CloudWatch
Azure Monitor
Google Cloud LoggingRead before the first live run.
- How to test a workflow before it touches anything realStatic validation, a dry run against real config with side effects held back, then a first live run on one record. A practical order for shipping automations safely.
- How to keep an AI agent’s spending close to the number you setA retry loop, a huge tool result or a growing prompt can turn one agent into a runaway bill. Here’s how per-tenant budgets and a circuit breaker limit it.
- How much a dry run actually proves before you trust it liveA dry run executes your workflow with side effects suppressed and shows each step’s output shape. That shows the path resolves, not that the result is right.
See a workflow run on your own use case.
Book a technical demo. Bring an n8n file or pick a template, and we build it with you on the canvas while Workflow Health checks it before it ever runs.