AnsibleCLI icon
Process icon
Get icon
Post icon
SlackIncomingWebhook icon
Schedule icon

Open a ServiceNow Incident on Failure with CMDB Severity

Auto-open a ServiceNow incident when a Kestra pipeline fails. Pull severity from the CMDB, set the right priority, and alert Slack. No manual triage.

Categories
Business

Turn pipeline failures into properly triaged ServiceNow incidents without anyone watching a dashboard. This blueprint monitors a scheduled job, and the moment it fails it looks up the affected service in your ServiceNow CMDB, opens an incident at the priority that service already carries, and posts a Slack alert. Instead of generic "something broke" pages, your on-call team gets an incident with the correct severity, the failing service attached, and links back to the exact Kestra execution. It closes the gap between orchestration failures and your ITSM process so nothing slips through unnoticed and nothing gets over-paged.

How it works

  • A monitored_job task runs an Ansible playbook via io.kestra.plugin.ansible.cli.AnsibleCLI on the io.kestra.plugin.core.runner.Process runner. This stands in for whatever job you want to watch.
  • A scheduled_run trigger (io.kestra.plugin.core.trigger.Schedule) fires the job on a cron of 0 */4 * * *. It ships disabled so you can wire in your real job first.
  • When the job fails, the errors block runs. lookup_cmdb (io.kestra.plugin.servicenow.Get) queries the cmdb_ci_service table with query: name={{ inputs.service_name }} and fetchType: FETCH_ONE to fetch the service record.
  • open_incident (io.kestra.plugin.servicenow.Post) creates a row in the incident table, setting priority from outputs.lookup_cmdb.results[0].priority with a fallback of 3, plus a short description and the failing cmdb_ci.
  • alert (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a message that an incident was opened for the failed execution.

What you get

  • Incidents created automatically on failure, no manual ticket entry.
  • Severity driven by the CMDB, so priority matches the business criticality of the service.
  • A Slack heads-up the moment an incident is opened.
  • Incident text that links back to the failing flow.id and execution.id for fast root-cause.

Who it's for

  • Platform and SRE teams running ITSM on ServiceNow.
  • Data and DevOps engineers who need failures to reach on-call through the official incident process.
  • Operations teams that want priority to reflect service criticality, not guesswork.

Why orchestrate this with Kestra

ServiceNow workflows and the CMDB describe your services, but ServiceNow has no view into when your data pipelines or infrastructure jobs actually fail. Kestra fills that gap. Event-driven errors handlers run only on failure, so incidents open exactly when they should. Built-in retries let transient blips recover before a ticket is ever created. Everything is declarative YAML you can version and review, execution outputs give you lineage from the failure to the incident, and the schedule trigger covers jobs that ServiceNow's own scheduler would never see.

Prerequisites

  • A ServiceNow instance with API access and a cmdb_ci_service record for the monitored service.
  • Ansible installed on the worker (the sample job uses the Process runner), or your own job swapped in.
  • A Slack incoming webhook.

Secrets

  • SN_DOMAIN: your ServiceNow instance domain.
  • SN_USERNAME: ServiceNow API username.
  • SN_PASSWORD: ServiceNow API password.
  • SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

  1. Add the secrets above to your Kestra namespace.
  2. Replace the sample inventory and playbook with your real Ansible job, or swap monitored_job for the task you want to watch.
  3. Set the service_name input to the CMDB service that the job maps to.
  4. Enable the scheduled_run trigger (it ships disabled) or attach your own trigger; a failure now opens an incident automatically.

How to extend

  • Map CMDB attributes to a richer priority or urgency model instead of the simple priority fallback.
  • Add assignment group, category, or impact fields to the incident data payload.
  • Replace the Ansible job with a dbt, Python, or any other Kestra task and reuse the same error handler.
  • Add a follow-up io.kestra.plugin.servicenow.Post or Get to comment on or close the incident when the next run succeeds.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.