New to Kestra?
Use blueprints to kickstart your first workflows.
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.
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.
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.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.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.flow.id and execution.id for fast root-cause.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.
cmdb_ci_service record for the monitored service.SN_DOMAIN: your ServiceNow instance domain.SN_USERNAME: ServiceNow API username.SN_PASSWORD: ServiceNow API password.SLACK_WEBHOOK_URL: Slack incoming webhook URL.monitored_job for the task you want to watch.service_name input to the CMDB service that the job maps to.scheduled_run trigger (it ships disabled) or attach your own trigger; a failure now opens an incident automatically.priority fallback.incident data payload.io.kestra.plugin.servicenow.Post or Get to comment on or close the incident when the next run succeeds.