New to Kestra?
Use blueprints to kickstart your first workflows.
Automate incident response with Kestra. Create a Jira ticket, send a Slack alert, generate an incident timeline, and log to PostgreSQL for audit.
Automate end-to-end incident response across Jira, Slack, and PostgreSQL. When an incident is declared, this Kestra flow opens a structured Jira ticket, alerts your on-call team in Slack with a rich Block Kit message, generates a timeline and postmortem report, and writes a permanent audit record to a database. It replaces the manual, error-prone scramble of copy-pasting incident details across tools with a single reproducible, observable workflow that keeps ticketing, alerting, and audit logging consistent every time.
service, severity (a SELECT of P1 to P4), description, jira_project_key, and slack_channel.create_jira_ticket (io.kestra.plugin.jira.issues.Create) opens an issue in the target project with a severity-prefixed summary, a formatted incident report body, a UTC timestamp, and incident plus severity-derived labels. It returns the ticket key for downstream tasks.alert_slack (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a Block Kit alert to the on-call channel, embedding the service, severity, the Jira key from outputs.create_jira_ticket.key, and the description.generate_timeline_report (io.kestra.plugin.scripts.python.Script) builds an incident timeline document with event timestamps and postmortem placeholders, exposed as a Kestra output.log_incident_to_postgres (io.kestra.plugin.jdbc.postgresql.Queries) appends an audit row to the incident_log table with an ON CONFLICT DO NOTHING guard so reruns stay idempotent.Jira, Slack, and Postgres each solve one slice of incident response, but none can coordinate the others. Kestra ties them into one declarative YAML flow where the Jira ticket key flows into the Slack alert and the database insert. You get event triggers (call this from a monitoring webhook or alert), automatic retries on transient API failures, full execution lineage across all four tasks, and a single source of truth no individual tool's scheduler can provide.
incident_log tableJIRA_DOMAINJIRA_USERNAMEJIRA_API_TOKENSLACK_WEBHOOK_URLPOSTGRES_URLPOSTGRES_USERPOSTGRES_PASSWORDincident_log table (columns: jira_key, service, severity, description, created_at) with a unique constraint on jira_key.severity to escalate P1 incidents to PagerDuty or page a manager