JSONStructuredExtraction icon
OpenAI icon
If icon
Return icon
SlackIncomingWebhook icon
Webhook icon

AI-Powered Incident Triage & Automated Response

Use AI to analyze production incidents, determine severity and customer impact, recommend an initial response, and automatically escalate urgent incidents through Slack.

Categories
AIInfrastructure

AI-Powered Incident Triage & Automated Response

Production incidents often arrive as unstructured alerts, monitoring events, application errors, infrastructure notifications, or customer reports. During an incident, engineers need to quickly understand the severity, scope, customer impact, and appropriate first response.

This Blueprint automates the first stage of incident response by using an AI model to transform an unstructured incident description into structured incident intelligence.

What this Blueprint does

The workflow:

  1. Receives an incident through configurable workflow inputs.
  2. Analyzes the incident using an AI model.
  3. Extracts structured incident intelligence.
  4. Determines the incident severity.
  5. Determines the affected category.
  6. Estimates customer impact.
  7. Assigns an AI confidence level.
  8. Generates a recommended first-response action.
  9. Routes urgent incidents through a conditional flow.
  10. Sends urgent incidents to the engineering team through Slack.
  11. Records lower-severity incidents for normal investigation.
  12. Produces a final incident-triage summary.

Workflow

The workflow follows this sequence:

Incident ↓ AI Structured Analysis ↓ Severity + Category + Customer Impact ↓ Confidence + Recommended Action ↓ Conditional Routing ↓ ┌───────────────────────┐ │ P0 Critical / P1 High │ └───────────┬───────────┘ │ Yes ──┴── No ↓ ↓ Slack Alert Routine Investigation ↓ ↓ └────┬────┘ ↓ Final Summary

AI-generated incident intelligence

For each incident, the AI determines:

  • Severity: P0 Critical, P1 High, P2 Medium, or P3 Low
  • Category: availability, performance, security, data, or other
  • Customer impact: none, low, medium, high, or widespread
  • Confidence: low, medium, or high
  • Recommended action: a concise initial response for engineers

Severity model

P0 Critical

Widespread or severe production impact requiring immediate response.

Examples include:

  • Major production outage
  • Widespread API failure
  • Critical service unavailable
  • Severe customer-facing failure

P1 High

Significant production impact requiring urgent engineering attention.

Examples include:

  • Large percentage of failed requests
  • Major degradation of a production service
  • Significant customer-facing errors
  • Important production functionality unavailable

P2 Medium

Limited impact that should be investigated during normal operations.

Examples include:

  • Partial degradation
  • Limited customer impact
  • Non-critical service problems
  • Performance issues with limited scope

P3 Low

Informational, minor, or low-impact issue that does not require immediate escalation.

Automated routing

P0 and P1 incidents are automatically routed to the urgent-response path.

The urgent path:

  • Creates an escalation summary.
  • Sends a Slack notification.
  • Includes the AI assessment.
  • Includes the recommended response.
  • Includes the affected service.
  • Preserves the original incident information.

P2 and P3 incidents follow the routine investigation path and do not generate an urgent Slack escalation.

Example incident

A monitoring platform reports that a production API is returning HTTP 500 errors for a large percentage of requests and customers are experiencing failed requests.

The AI can classify the event as a high-severity availability incident, estimate customer impact, provide a confidence level, and recommend an initial engineering response.

Example AI result

A possible structured assessment can look like:

  • Severity: P1 High
  • Category: availability
  • Customer impact: high
  • Confidence: high
  • Recommended action: investigate the API deployment and error logs, verify upstream dependencies, and begin rollback or mitigation if the failure is deployment-related.

The exact result depends on the incident information provided to the AI model.

Integration possibilities

This Blueprint can receive incidents from:

  • Monitoring platforms
  • Observability systems
  • Application alerting
  • Infrastructure monitoring
  • API gateways
  • Customer support platforms
  • Incident-management systems
  • Custom internal systems

The webhook trigger can be connected to external alerting systems that send incident information into Kestra.

Possible extensions

The workflow can be extended with:

  • PagerDuty escalation
  • Jira incident creation
  • Email notifications
  • Microsoft Teams notifications
  • Incident databases
  • Runbook retrieval
  • RAG-based troubleshooting
  • Automated remediation
  • Service ownership lookup
  • Post-incident reporting
  • Incident metrics and analytics

Prerequisites

Before running this Blueprint, make sure you have:

  • A running Kestra instance.
  • Access to an OpenAI API key.
  • Access to a Slack incoming webhook if urgent notifications are required.
  • The Kestra AI plugin available in the environment.

Required secrets

The workflow expects the following Kestra secrets:

  • OPENAI_API_KEY Used to authenticate requests to the OpenAI provider.

  • SLACK_WEBHOOK_URL Used to send urgent incident notifications to Slack.

Credentials must be configured in the Kestra secret backend. Never place real credentials directly inside the Blueprint YAML.

Quick start

  1. Add the Blueprint to a Kestra instance.
  2. Configure the OPENAI_API_KEY secret.
  3. Configure the SLACK_WEBHOOK_URL secret if Slack escalation is required.
  4. Execute the flow using the default incident inputs.
  5. Review the AI structured extraction output.
  6. Review the conditional routing result.
  7. For P0 or P1 incidents, check the configured Slack channel.
  8. Review the final incident summary.

Inputs

incident_title

Short title describing the incident.

Example:

Production API returning HTTP 500 errors

incident_description

Detailed description of the incident including symptoms, scope, affected users, and observed impact.

affected_service

Name of the application, service, or infrastructure component affected by the incident.

Outputs

The primary AI analysis is available from:

outputs.analyze_incident.extractedJson

The structured result contains:

  • severity
  • category
  • customer_impact
  • confidence
  • recommended_action

The workflow also produces:

outputs.incident_summary

which contains the final incident-triage summary.

Security

Credentials are stored using Kestra secrets and are never hardcoded in the workflow.

The Blueprint uses:

  • {{ secret('OPENAI_API_KEY') }}
  • {{ secret('SLACK_WEBHOOK_URL') }}

No credential values are included in this Blueprint.

Customization

Teams can customize this Blueprint by:

  • Changing the incident inputs.
  • Adjusting the AI system instructions.
  • Adding new incident categories.
  • Changing severity thresholds.
  • Adding additional escalation channels.
  • Connecting ticketing systems.
  • Adding incident databases.
  • Adding runbook or RAG retrieval.
  • Adding automated remediation tasks.
  • Adding additional AI analysis stages.

The conditional routing remains deterministic after the AI produces the structured incident assessment.

See How

New to Kestra?

Use blueprints to kickstart your first workflows.