> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kodostatus.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflows & Automation
> Automate incident response with trigger-based workflows
Workflows let you automate repetitive tasks and incident response. When something happens (an incident is created, a monitor goes down, an alert fires), Kodo can automatically take action—notify the right people, update services, or call external webhooks.
## Why Use Workflows?
Automate initial incident response so your team can focus on resolution
Ensure the same steps happen every time, reducing human error
Connect Kodo to your existing tools and processes
Automatically escalate if incidents aren't acknowledged
## Workflow Components
Every workflow has three parts:
### 1. Triggers
What starts the workflow:
| Trigger | Description |
| -------------------------- | --------------------------------------------- |
| `incident.created` | New incident is opened (including drafts) |
| `incident.updated` | Incident status or message changes |
| `incident.resolved` | Incident is marked resolved |
| `alert.fired` | Alert is triggered via webhook or integration |
| `alert.resolved` | Alert is resolved (auto or manual) |
| `service.status_changed` | Service status updates |
| `uptime.down` | Uptime monitor detects failure |
| `uptime.recovered` | Uptime monitor recovers |
| `heartbeat.missed` | Heartbeat monitor misses expected check-in |
| `incident.published` | Draft incident is published to status page |
| `error_threshold_exceeded` | Error count exceeds configured threshold |
| `scheduled` | Interval-based schedule |
| `manual` | Triggered on-demand via API or dashboard |
### 2. Conditions (Optional)
Filter when the workflow should run:
```json theme={null}
{
"operator": "AND",
"conditions": [
{ "field": "severity", "operator": "equals", "value": "critical" },
{ "field": "service.name", "operator": "contains", "value": "production" }
]
}
```
Supported operators:
* `equals`, `not_equals`
* `contains`, `not_contains`
* `greater_than`, `less_than`
* `in`, `not_in`
### 3. Actions
What the workflow does:
| Action | Description |
| --------------------- | --------------------------------------------------- |
| Send Notification | Send to all configured channels (Slack, email) |
| Send Slack Message | Send a message to a Slack webhook |
| Send Email | Send an email to specified recipients |
| Page On-Call | Trigger an on-call escalation policy |
| Create Incident | Open a new incident automatically |
| Update Incident | Change incident status, severity, or title |
| Resolve Incident | Mark an incident as resolved |
| Add Incident Update | Post a status update to an incident |
| Assign Incident | Assign an incident to a team member |
| Add Label | Add a label to an incident |
| Update Service Status | Change service status |
| Send Webhook | POST to an external URL |
| Acknowledge Alert | Auto-acknowledge a firing alert and stop escalation |
| Run Another Workflow | Chain workflows together (max depth: 3) |
| Delay | Pause before the next action |
## Example Workflows
### Critical Incident Response
When a critical incident is created, notify the on-call team and update the status page:
1. Go to **Dashboard → Workflows → Create Workflow**
2. Set trigger: `incident.created`
3. Add condition: `severity equals critical`
4. Add actions:
* Send notification to PagerDuty
* Send notification to #incidents Slack channel
* Execute webhook to your runbook system
```json theme={null}
{
"name": "Critical Incident Response",
"trigger": "incident.created",
"conditions": {
"operator": "AND",
"conditions": [
{ "field": "severity", "operator": "equals", "value": "critical" }
]
},
"actions": [
{
"type": "send_notification",
"channel_id": "ch_pagerduty"
},
{
"type": "send_notification",
"channel_id": "ch_slack_incidents"
},
{
"type": "execute_webhook",
"url": "https://runbooks.example.com/trigger",
"method": "POST"
}
]
}
```
### Auto-Create Incident on Outage
When uptime monitoring detects a failure, automatically create an incident:
```json theme={null}
{
"name": "Auto-Incident on Outage",
"trigger": "uptime.down",
"actions": [
{
"type": "create_incident",
"title": "{{monitor.name}} is unreachable",
"severity": "major",
"service_id": "{{monitor.service_id}}",
"message": "Uptime monitor detected {{monitor.url}} is not responding. Automated incident created."
}
]
}
```
Incidents created by workflows follow your organization's **auto-incident visibility** setting. If you have draft mode enabled, workflow-created incidents will also start as drafts and won't appear on the public status page until published. Configure this in **Settings > Automation** or see [Incident Safeguards](/automation/incident-safeguards#draft-mode).
### Scheduled Health Check Report
Send a daily summary of system health:
```json theme={null}
{
"name": "Daily Health Report",
"trigger": "scheduled",
"schedule": "0 9 * * *",
"actions": [
{
"type": "execute_webhook",
"url": "https://api.example.com/generate-report"
},
{
"type": "send_notification",
"channel_id": "ch_slack_ops",
"message": "Daily health report generated. View at https://dashboard.example.com/reports"
}
]
}
```
## Workflow Variables
Use variables in your workflow actions:
| Variable | Description |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| `{{incident.id}}` | Incident ID |
| `{{incident.title}}` | Incident title |
| `{{incident.severity}}` | Incident severity |
| `{{incident.status}}` | Current status |
| `{{incident.source}}` | How the incident was created: `manual`, `api`, `auto_uptime`, `auto_heartbeat`, `auto_integration`, `auto_beacon` |
| `{{incident.visibility}}` | `draft` or `public` |
| `{{service.id}}` | Affected service ID |
| `{{service.name}}` | Service name |
| `{{monitor.name}}` | Monitor name |
| `{{monitor.url}}` | Monitored URL |
| `{{alert.message}}` | Alert message |
| `{{timestamp}}` | Event timestamp |
## Workflow Runs
View execution history on each workflow's detail page (**Dashboard → Workflows → Select Workflow**):
* **Status**: `completed`, `failed`, `running`
* **Duration**: How long the workflow took
* **Actions**: Which actions succeeded/failed
## Workflows and Draft Incidents
If your organization uses [draft mode](/automation/incident-safeguards#draft-mode), auto-created incidents start hidden from the public status page. This affects how workflows interact with incidents:
* **`incident.created`** fires for both drafts and public incidents. Use the condition `visibility equals draft` or `visibility equals public` to distinguish.
### Example: Internal Alert on Draft Creation
Alert your team in Slack when a draft is created so they can review it, without notifying subscribers:
```json theme={null}
{
"name": "Draft Review Alert",
"trigger": "incident.created",
"conditions": {
"operator": "AND",
"conditions": [
{ "field": "visibility", "operator": "equals", "value": "draft" }
]
},
"actions": [
{
"type": "send_notification",
"channel_id": "ch_slack_ops",
"message": "Draft incident created: {{incident.title}} ({{incident.severity}}). Review and publish at https://kodostatus.com/dashboard/incidents"
}
]
}
```
Learn about draft mode, auto-publish, flap protection, cooldowns, and other safeguards for auto-created incidents.
## Best Practices
Begin with basic workflows (notification on critical incident) and add complexity as you understand your needs.
Don't trigger on every event. Use conditions to filter for actionable situations.
Create a test workflow with `manual` trigger to validate your actions before connecting to real events.
If one action fails, the workflow can continue executing remaining actions.
Regularly review failed workflows to catch integration issues early.