Open a GitLab Issue Automatically on Pipeline Failure

Turn silent pipeline failures into tracked GitLab issues automatically. This blueprint monitors a scheduled job and, the moment it fails, files a GitLab issue containing the failing flow context and a link back to the Kestra execution, then posts a Slack notification. The incident lands in your team's existing GitLab tracker without anyone watching dashboards, parsing logs, or copying details into an issue by hand. It closes the gap between "a job broke" and "someone is accountable for fixing it" so failures never go unnoticed.

How it works

• A io.kestra.plugin.core.trigger.Schedule trigger runs the flow on a cron (0 */6 * * *, shipped disabled so you can wire in your own job first).
• The monitored_job task (io.kestra.plugin.scripts.shell.Commands on the Process runner) stands in for the real work you want watched.
• When that task fails, the errors block fires. The open_issue task (io.kestra.plugin.gitlab.issues.Create) opens a GitLab issue with a timestamped title, a markdown body listing the flow, execution id, and start time, plus incident and service-name labels.
• The notify task (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a short message so the team sees the incident immediately.

What you get

• Every failure tracked as a GitLab issue, never lost in a log stream.
• A direct execution link for fast inspection and retry.
• Auto-applied incident and per-service labels for triage and filtering.
• A Slack ping the moment an incident issue is created.

Who it's for

• Data and platform engineers who already triage in GitLab.
• On-call and SRE teams that need failures to become accountable, assignable work.
• Teams standardizing incident capture across many pipelines.

Why orchestrate this with Kestra

GitLab's own CI scheduler can run jobs, but it cannot watch an arbitrary external pipeline and open an issue when that pipeline fails. Kestra fills that gap: event-driven errors handlers fire only on failure, declarative YAML keeps the whole monitor-and-report logic in one versioned file, retries and execution lineage are built in, and you can fan the same pattern across every flow without bespoke scripting.

Prerequisites

Secrets

• GITLAB_TOKEN: GitLab personal access token with api scope.
• GITLAB_PROJECT_ID: target GitLab project ID.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

The incident and service-name labels should exist in the project, or remove the labels block.

Quick start

1. Add the three secrets above to your Kestra namespace.
2. Replace the monitored_job task with your real job and set the service_name input.
3. Enable the scheduled_run trigger; any failure now opens an issue and pings Slack automatically.

How to extend

• For self-hosted GitLab, add url and apiPath to the open_issue task to target your instance.
• Raise a merge request instead of an issue by swapping in io.kestra.plugin.gitlab.mergerequests.Create.
• Replace the Schedule trigger with a Flow or webhook trigger to monitor other workflows or external events.
• Read outputs.open_issue.webUrl to attach the new issue link to downstream alerts.

Links

• Plugin docs: https://kestra.io/plugins/plugin-gitlab
• Orchestrate GitLab with Kestra: https://kestra.io/orchestration/gitlab