Build automated workflows using natural language, drag-and-drop, CLI, SDK, or MCP
Kestrel workflows let you chain AI-powered actions across 15+ integrations into automated pipelines. Workflows are triggered by events — Kubernetes incidents, cloud alerts, Slack messages, PagerDuty alerts, and more — and execute a sequence of steps that investigate, fix, and notify.
Describe the workflow you want in plain English. The Workflow Agent interprets your intent, selects the right triggers and actions, wires up template variables, and generates a complete workflow on the canvas.
1
Open the workflow builder
Navigate to Workflows → All Workflows in the Kestrel dashboard and click Create Workflow.
2
Describe your workflow
Type a natural language description of what you want automated. Be specific about the trigger, the actions, and where results should go.
3
Review and adjust
The Workflow Agent generates the workflow on the canvas. Review each step and iterate the prompt to adjust configuration, add, or remove steps as needed.
4
Save and enable
Click Save to activate the workflow. It will begin responding to its configured trigger immediately.
Example prompts:
“When a K8s incident is detected, run root cause analysis, send the RCA to #incidents in Slack, and create a Jira ticket with the details.”
“When someone requests a new service in Slack, generate the K8s manifests, open a GitOps PR in GitHub, and sync with ArgoCD.”
“When a Vercel deployment fails, pull the build logs, run an AI investigation, and notify the team in Slack.”
“When a Railway service crashes, fetch the logs, investigate the root cause, roll back to the previous deployment, and alert #platform in Slack.”
“When AWS costs spike, run a cost anomaly analysis and post a report to #finops in Slack.”
The more specific your description, the better the generated workflow. Include the trigger source, desired actions, and output destinations.
The visual canvas gives you full control over workflow construction. Add triggers and actions from the sidebar, connect them into a pipeline, and configure each step individually.
Triggered on a recurring cadence rather than by an external event. Ideal for periodic cost reports, cleanup scans, and audits. Configure the interval (hourly, daily, weekly, or monthly), the time of day (UTC), and — for weekly/monthly schedules — the day of week or day of month.
Trigger Block
Description
Recurring Schedule
Triggers on a recurring schedule (hourly, daily, weekly, or monthly)
Scheduled triggers expose {{signal.schedule_interval}}, {{signal.fired_at}}, and {{signal.fired_date}} to downstream steps.
Triggered by Fly.io machine lifecycle changes. Fly.io has no outbound webhooks, so Kestrel detects these events by polling the Fly Machines API and diffing machine state on a configurable interval. Filter by app, region, and event type, and set the poll cadence (1m / 5m / 15m / 30m).
Trigger Block
Description
Machine Crashed
Triggers when a Fly machine crashes (non-zero exit / OOM)
Machine Stopped
Triggers when a machine transitions to stopped/suspended
Machine Started
Triggers when a machine transitions to started
App Down
Triggers when all of an app’s machines are stopped/unhealthy
Triggered by Nebius GPU/compute and Managed Kubernetes node changes. Nebius has no outbound webhooks, so Kestrel detects these events by polling the Nebius compute and Managed Kubernetes APIs and diffing instance state and node conditions on a configurable interval. Filter by project, cluster, and event type, and set the poll cadence (1m / 5m / 15m / 30m).
Trigger Block
Description
GPU Error
Triggers when a node reports a GPU error condition
Maintenance Scheduled
Triggers when a node has scheduled maintenance
Node Not Ready
Triggers when a Kubernetes node leaves the Ready state
Instance Stopped
Triggers when a compute instance transitions to stopped
Triggered by Jenkins build lifecycle events, delivered by a webhook notification plugin (or a post-build curl step) authenticated with a per-tenant shared secret. Filter by job name (full path for folder-nested jobs) and build status.
Trigger Block
Description
Build Failed
Triggers when a build completes with FAILURE
Build Unstable
Triggers when a build completes UNSTABLE (e.g. test failures)
Triggered by CircleCI’s native outbound webhooks (workflow-completed / job-completed), signed with HMAC-SHA256 and verified by Kestrel. Filter by project slug, branch, and status.
Trigger Block
Description
Workflow Failed
Triggers when a workflow completes with failed or error status
Workflow Succeeded
Triggers when a workflow completes successfully
Workflow Completed (any status)
Triggers when a workflow finishes with any status
Job Failed
Triggers when a job completes with failed status (finer-grained than workflow-completed)
Triggered by Terraform Cloud (HCP Terraform) run lifecycle and drift events, delivered by per-workspace notification configurations (webhooks) signed with HMAC-SHA512 and verified by Kestrel. Filter by workspace, event type, and run status.
Trigger Block
Description
Run Created
Triggers when a new run is queued on a workspace
Run Planning
Triggers when a run starts planning
Run Needs Attention
Triggers when a plan finishes and the run awaits confirmation
Run Applying
Triggers when a run starts applying
Run Completed
Triggers when a run applies successfully or finishes as planned-and-finished
Run Errored
Triggers when a run fails (plan/apply error, policy hard-fail)
Drift Detected
Triggers when a workspace health assessment detects infrastructure drift
Assessment Check Failed
Triggers when a workspace health assessment fails to run
Triggered by Pulumi Cloud stack, update, deployment, drift, and policy events, delivered by organization or stack webhooks signed with HMAC-SHA256 (Pulumi-Webhook-Signature) and verified by Kestrel. Filter by stack (project/stack reference), project, and event type.
Trigger Block
Description
Update Succeeded
Triggers when a stack update (pulumi up) succeeds
Update Failed
Triggers when a stack update, refresh, or destroy fails
Preview Failed
Triggers when a stack preview fails
Destroy Succeeded
Triggers when a stack destroy succeeds
Deployment Started
Triggers when a Pulumi Deployments run starts executing
Deployment Succeeded
Triggers when a Pulumi Deployments run succeeds
Deployment Failed
Triggers when a Pulumi Deployments run fails
Drift Detected
Triggers when a drift detection run finds infrastructure drift
Drift Run Failed
Triggers when a drift detection or remediation run fails
Policy Violation
Triggers when a CrossGuard policy violation is detected
Stack Created
Triggers when a new stack is created in the organization
Stack Deleted
Triggers when a stack is deleted from the organization
Triggered by an HTTP POST to a unique webhook URL. Accepts any JSON payload with optional HMAC signature verification. See Custom Integrations for details.
Query Cost Explorer, Get Cost Anomalies, Get Cost Forecast, Get Budget Status, Get Rightsizing Recommendations, Get Savings Plans Recommendations, Get Reservation Recommendations, Get Commitment Utilization, Compare Cost Periods, Find Idle Resources, Get Compute Optimizer Recommendations, Get Trusted Advisor Cost Checks, Stop EC2 Instances, Delete Unattached EBS Volumes, Release Elastic IPs, Delete Old Snapshots
PostHog
Get Session Summary, Get Session Recording, Query Events, List Session Recordings, Get Error Issue
Vercel
Get Deployment, Get Build Logs, Rollback Production, Promote to Production, List Deployments, Investigate Vercel
Railway
Get Deployment, Get Deployment Logs, Rollback, Redeploy, Restart, List Deployments, Set Variables, Investigate Railway
Fly.io
Restart Machine, Start Machine, Stop Machine, Suspend Machine, Cordon Machine, Uncordon Machine, Get Machine, Get Machine Events, List Machines, Set Secrets, Investigate Fly
Nebius AI Cloud
Get Instance, Start Instance, Stop Instance, Restart Instance, List Instances, List Clusters, List Node Groups, Scale Node Group, Investigate Nebius
Terraform Cloud
List/Get Workspace, Lock/Unlock/Force-Unlock Workspace, List/Get Run, Create Run (Plan), Create Destroy Run, Apply Run, Discard Run, Cancel Run, Wait for Run, Get State Outputs, List Variables, Set Variable, Get Drift Assessment, Investigate Terraform
Pulumi Cloud
List/Get Stack, List/Get Update, Run Deployment, Get/Wait for/Cancel Deployment, Pause/Resume Deployments, Get Stack Outputs, Get Drift Status, Set/Delete Stack Tag, Investigate Pulumi
Approval Gates
Wait for Manual Approval, Wait for Slack Approval, Wait for PR/MR Approval, Refine RCA with Feedback
Custom HTTP & Webhooks
Create custom action blocks to call any API endpoint, and custom webhook triggers to start workflows from external systems. See Custom Integrations.
The Cloud Cost remediation blocks (Stop EC2 Instances, Delete Unattached EBS Volumes, Release Elastic IPs, Delete Old Snapshots) mutate real infrastructure. Always place them behind an Approval Gate. Resources tagged kestrel:protected are always skipped, every remediation block is pinned to an explicit region, and safety caps limit how many resources a single run can touch.
{{incident.title}} — Data from the trigger event{{rca_result.root_cause}} — Promoted field from RCA actions{{step_outputs.action-1.summary}} — Output from a specific action step{{request.prompt}} — User input (for Slack request triggers)
When configuring an action step, click the Variables button on any text field to open the variable picker. It shows all available variables from the trigger and preceding steps, grouped by source. The picker is DAG-aware — it only shows variables that will be available at runtime based on the step’s position in the workflow.
The variable picker only shows variables that are available at the current step’s position in the workflow. Move a step earlier or later to change which variables it can access.
The workflow waits for the associated pull request or merge request to be approved or merged (webhook-driven). Merging the PR approves the step; closing it rejects it.
A self-looping review gate for incident-response workflows. Place it after a Trigger K8s RCA or Trigger Cloud RCA step. It presents the root cause and proposed fix for review with three outcomes:
Approve — continues on the approved branch (e.g. apply the fix, publish the runbook).
Reject — continues on the rejected branch.
Request changes — you provide free-text guidance (“the real cause is the readiness probe timeout, not the image tag”), and the RCA agent re-runs with your feedback and comes back for review again. Feedback accumulates across rounds, so each pass builds on the last.
The loop repeats until you approve or reject, capped by Max Refine Rounds (default 5). When the cap is hit, the workflow advances on the approved branch. Choose Kestrel UI or Slack as the review channel in the block config.
The Poll Until block (Flow Control) repeatedly runs a single catalog action at a fixed interval and evaluates an exit condition against each iteration’s output. It’s the building block for “wait for X to reach state Y” automation — waiting for a sandbox to stop, a deployment to become healthy, a pipeline to finish, or a cloud resource to reach a target state.Drag Poll Until from the sidebar (next to Conditions) onto the canvas, then configure:
Action to Poll — any catalog action (searchable dropdown). Its config fields appear below and behave exactly like the standalone action block, including dynamic dropdowns (e.g. Cluster → Namespace scoping) and template variables.
Output Field Path — which output field of the polled action to test, chosen from the action’s known outputs.
Operator + Value — equals, not_equals, contains, not_contains, exists, not_exists. Where the output has known discrete values (states, statuses) or refers to live resources (cluster IDs), the Value field is a dropdown. You can select multiple values: equals/contains are met when the output matches ANY selected value; not_equals/not_contains are met only when it matches NONE.
Poll Interval — how often to re-run the action (default 60s, minimum 30s).
Timeout — how long to keep polling (default 60 minutes).
The block has two outgoing branches:
met — the exit condition held on some iteration; downstream steps see the final iteration’s output.
timeout — the timeout elapsed before the condition was met.
Polling is durable. The loop’s schedule is persisted server-side, so a server restart mid-interval resumes the countdown where it left off instead of restarting the interval — and in-flight loops survive redeployments.
The Generate Runbook action (Kestrel) distills a completed RCA and its fixes into a reusable, generalized runbook for that class of incident — symptom, diagnosis steps, remediation steps, verification, and rollback. It requires an upstream RCA step. The generated runbook is available to downstream steps as {{runbook_html}} / {{runbook_markdown}}, and Publish Runbook Entry (Confluence) consumes runbook_html automatically.
Workflow Agent prompt:“When a Kubernetes incident is detected in any cluster, run root cause analysis, send the root cause and recommended fix to #incidents in Slack, and create a Jira ticket in the INFRA project with the full investigation summary.”
A full human-in-the-loop loop: detect the incident, run RCA, draft a reusable runbook, let an engineer iteratively refine the analysis, then apply the fix and publish the runbook.Workflow Agent prompt:“When a Kubernetes pod crashes, run root cause analysis, generate a runbook, then let me review and refine the analysis before applying — when I approve, apply the YAML fix and publish the runbook to Confluence; if I reject, notify #incidents.”
Step
Type
Configuration
Trigger
Any Kubernetes Incident
All clusters
Action 1
Trigger K8s RCA & Generate Fix
Include metrics and logs
Action 2
Generate Runbook
Audience: SRE, include rollback
Approval
Refine RCA with Feedback
Channel: Kestrel UI, Max Refine Rounds: 3
On Approved → Action 3
Apply YAML Fix
Auto-detected from RCA
On Approved → Action 4
Publish Runbook Entry (Confluence)
Uses {{runbook_html}}
On Rejected → Action 5
Slack Send Message
Channel: #incidents, message: RCA rejected by reviewer
On Request changes, the reviewer’s free-text guidance re-runs the RCA agent and the gate re-opens — repeating until approve/reject or the round cap.
Workflow Agent prompt:“When someone requests a new Kubernetes resource via /kestrel-workflow in Slack, generate the K8s manifests based on their request, create a pull request in acme/k8s-manifests on GitHub, wait for the PR to be merged, then trigger an ArgoCD sync.”
Workflow Agent prompt:“When a Vercel deployment fails, fetch the build logs, run an AI investigation to identify the root cause of the build failure, and send the findings to #deploys in Slack.”
Step
Type
Configuration
Trigger
Vercel Deployment Failed
All projects
Action 1
Get Build Logs
Deployment: {{signal.deployment_id}}
Action 2
Investigate Vercel
Query: analyze build logs from {{step_outputs.action-1.summary}}
Workflow Agent prompt:“When a Railway service crashes, fetch the deployment logs, run an AI investigation to find the root cause, roll the service back to its previous deployment, and post a summary to #platform in Slack.”
Step
Type
Configuration
Trigger
Railway Deployment Crashed
All projects
Action 1
Get Deployment Logs
Deployment: {{signal.deployment_id}}
Action 2
Investigate Railway
Query: analyze crash logs from {{step_outputs.action-1.summary}}
Workflow Agent prompt:“When a Fly.io machine crashes, pull its recent events, run an AI investigation to find the root cause, restart the machine, and post a summary to #platform in Slack.”
Workflow Agent prompt:“When a Nebius GPU node reports an error, run an AI investigation to find the root cause, add a node to the affected node group, and post a summary to #ml-infra in Slack.”
Step
Type
Configuration
Trigger
Nebius GPU Error
All projects, poll every 5m
Action 1
Investigate Nebius
Query: find why node {{signal.node_name}} reported a GPU error
Workflow Agent prompt:“When a Jenkins build fails, fetch the console log, run an AI investigation to identify the root cause of the failure, post the findings to #ci in Slack, and create a Jira ticket in the INFRA project.”
Workflow Agent prompt:“When a CircleCI workflow fails on main, rerun only the failed jobs, wait for the pipeline to finish, and page on-call via PagerDuty with an AI investigation summary if the rerun also fails.”
Step
Type
Configuration
Trigger
CircleCI Workflow Failed
Projects: all, branch: main
Action 1
Rerun Workflow
Workflow: {{signal.workflow_id}}, from failed jobs only
Workflow Agent prompt:“When PostHog captures a frontend exception, generate an AI summary of the user’s session including what they were doing before the error, and send the summary with the replay URL to #product-alerts in Slack.”
Step
Type
Configuration
Trigger
PostHog Session Error/Exception
All events
Action 1
Get Session Summary
Session: {{signal.session_id}}
Action 2
Slack Send Message
Channel: #product-alerts, message: {{step_outputs.action-1.summary}} with replay URL
Terraform Run Needs Attention → Plan Summary → Slack Approval → Apply
Workflow Agent prompt:“When a Terraform Cloud run on a production workspace finishes planning and needs confirmation, fetch the planned changes, ask for approval in #infra-approvals, and apply the run if approved or discard it if rejected.”
Workflow Agent prompt:“When a Pulumi Cloud update fails on a production stack, investigate the failure, post the findings to #infra-approvals in Slack and ask for approval, then retry the update if approved.”
Step
Type
Configuration
Trigger
Pulumi Update Failed
Stacks: prod-*
Action 1
Investigate Pulumi
Query: why did the update fail?, Stack: {{signal.stack}}
Action 2
Wait for Slack Approval
Channel: #infra-approvals, message includes {{step_outputs.action-1.summary}} and {{signal.update_url}}
Workflow Agent prompt:“When an AWS cost anomaly is detected, query the cost breakdown for the affected account over the last 7 days, run an AI cost analysis to identify the root cause and recommend optimizations, and post the analysis to #finops in Slack.”
Step
Type
Configuration
Trigger
Cost Anomaly Detected
All AWS accounts
Action 1
Query Cost Explorer
Account: {{signal.aws_account_id}}, time range: 7 days
Workflow Agent prompt:“Every Monday at 9am UTC, query last week’s AWS costs grouped by service, get savings plans recommendations, run an AI cost analysis, and post an executive summary to #finops in Slack.”
Workflow Agent prompt:“Every day at 8am UTC, scan for idle resources (unattached EBS volumes and unassociated Elastic IPs), ask for approval in #finops, and if approved delete the unattached volumes (snapshot first) and release the idle Elastic IPs.”
Step
Type
Configuration
Trigger
Recurring Schedule
Daily, 08:00 UTC
Action 1
Find Idle Resources
Resource types: EBS volumes, Elastic IPs; all enabled regions
Action 2
Wait for Slack Approval
Channel: #finops, message includes {{step_outputs.action-1.idle_count}} idle resources, est. savings {{step_outputs.action-1.estimated_monthly_savings}}
On Approved → Action 3
Delete Unattached EBS Volumes
Volume IDs: {{step_outputs.action-1.idle_volume_ids}}, snapshot first
Forecast Overrun → Compare Periods → Rightsizing → Slack
Workflow Agent prompt:“When the AWS cost forecast projects a budget overrun, compare this month’s spend to last month to find the biggest movers, get rightsizing recommendations, and post the analysis to #finops in Slack.”
