Steps & actions

Steps are the individual actions a workflow performs. Each step is defined in JSON and can use data from the triggering event to customize its behavior.

Step types

Step type	Description
Send notification	Send a message via Slack, PagerDuty, or email
Update incident	Change incident status, severity, or add a comment
Update status page	Set component status on a status page
Create ticket	Create a ticket in Jira, Linear, or GitHub Issues
HTTP request	Send an HTTP request to any external API
Delay	Wait for a specified duration before the next step
Conditional	Branch based on a condition

Defining a step

Each step is defined as a JSON object with a type and configuration:

{
  "type": "send_notification",
  "channel": "slack",
  "target": "#incidents",
  "message": "Incident {{incident.id}} declared as {{incident.severity}}: {{incident.title}}"
}

Template variables

Steps can reference incident data using {{variable}} syntax:

Variable	Description
{{incident.id}}	Incident identifier
{{incident.title}}	Incident title
{{incident.severity}}	Severity level (P1-P4)
{{incident.status}}	Current status
{{incident.type}}	Incident type
{{incident.commander}}	Commander's name
{{incident.url}}	URL to the incident in Batida

Conditional logic

Use conditional steps to branch your workflow based on incident properties:

{
  "type": "conditional",
  "condition": "{{incident.severity}} == 'P1'",
  "if_true": [
    { "type": "send_notification", "channel": "pagerduty", "target": "exec-escalation" }
  ],
  "if_false": [
    { "type": "send_notification", "channel": "slack", "target": "#incidents" }
  ]
}

Parallel execution

By default, steps run sequentially. To run steps in parallel, group them in a parallel block:

{
  "type": "parallel",
  "steps": [
    { "type": "send_notification", "channel": "slack", "target": "#incidents" },
    { "type": "update_status_page", "component": "API", "status": "degraded" }
  ]
}

Parallel steps are all started simultaneously. The workflow waits for all parallel steps to complete before moving to the next sequential step.

Error handling

When a step fails, the workflow behavior depends on your configuration:

On failure	Description
Stop	The workflow stops and logs the error
Continue	The workflow skips the failed step and continues
Retry	The workflow retries the step up to 3 times with backoff

By default, workflows use the Stop behavior. You can override this per step in the workflow editor.

Step execution logs

Every step execution is logged. You can view the logs from the workflow detail page to see:

• Which steps succeeded and which failed.
• The input data and output of each step.
• Execution timestamps and durations.