The moment it happens

Know right away when main fails

A failed pipeline on main reaches you with the jobs that broke and a link to it.

Runs: The moment it happens
Apps: GitLab
AI: Not needed
Access: read_api

Send this to your assistant

Create a ClickRuntime automation: email me when a GitLab pipeline on the main branch fails, listing the failed jobs and linking to the pipeline.

Paste it into your assistant. It tells you what it will send or change before it runs live.

Add to ChatGPT Add to Claude

First time? Adding ClickRuntime to your assistant takes about two minutes.

Why use it

Why teams use this automation

A failed pipeline on main is a stop sign for everyone: nothing should deploy, new branches are built on a broken base and the longer it stays red, the more commits pile up that could be the cause. GitLab's own emails go to the committer, who may be offline, so the failure is silent for the people who could actually help.

When GitLab sends a pipeline event, ClickRuntime checks whether the status is failed on the branch you chose. If it is, the failed jobs are listed and a notification goes out with the pipeline link, the commit author and the names of the jobs that broke, so the first person to see it knows where to look.

Teams that deploy from main and platform engineers who own the shared pipeline benefit most.

What you get out of it

Fixes start within minutes
Because the alert arrives as the pipeline fails, the person who pushed the commit is often still at their keyboard and can fix or revert before anyone else is blocked.
Failed jobs are named in the message
Listing which jobs failed, such as test or deploy, saves the first responder from opening the pipeline just to learn whether it is a flaky test or a real outage.
Shared awareness on main
A single notification to the team prevents each person finding out separately and asking in chat whether the build is broken for everyone. Fewer duplicated questions means calmer incident handling.
Fewer deploys on a broken base
Knowing main is red encourages people to hold their merges, which keeps broken code from piling up and keeps a clean revert possible. Reverting stays simple when nothing builds on a broken commit.
No noise from other branches
Limiting alerts to the branch you care about means a failing experiment branch never interrupts anyone, and each message is a signal worth acting on. Teams quickly learn to trust and act on a quiet, accurate channel.

How it works

What happens, step by step

When a GitLab pipeline finishes, GitLab tells ClickRuntime straight away.
ClickRuntime ignores everything except failed pipelines on the branch you chose, such as main.
It lists the jobs that failed.
You get an email with the project, branch, failed jobs and a link to the pipeline.

Before it runs live

Connect GitLab
Paste your automation's link into the other app's webhook settings

What you get

RunsThe moment it happens

Know right away when main failsjust nowSucceeded

Email · Pipeline failedPipeline failed on acme/web-app@main - test: unit-tests - lint: eslint

Build your own

Need it to work differently?

This template is a starting point. Copy the prompt and change it, or describe a different automation from scratch, with your own conditions, more apps or an AI step. Your assistant writes it, tests it and runs it on ClickRuntime.

Your own rules
Conditions, thresholds, filters and exceptions, written the way you'd explain them to a colleague.
Any number of apps
One automation can read from one app and update several others. Over 248 apps are ready, and anything with an API works too.
AI where it helps
Summaries, classification, extraction and drafts use ClickRuntime's built-in AI, with no extra key.
On a schedule or on each event
Runs as often as every 5 minutes, or the moment an app sends an event, and keeps track of what it already handled.

Changes you can ask for

Act only on the items that match your own rules, and skip the rest
Add an AI step, for example to summarize, sort or draft a reply
Add another app, for example also send it to Slack
Combine it with other GitLab steps into one automation

Under the hood

The code that runs this automation

This is the Python script that runs each time the automation starts. Your AI assistant writes it for you when you send the prompt, and you allow each step in your assistant. To change how the automation works, describe the change to your assistant and it updates the script for you. For every function it can use, see the script reference.

get_alerted_when_a_pipeline_fails.pyexample

from clickruntime import on_event, credentials, http, notify

GITLAB = "https://gitlab.com/api/v4"

def gl_headers():
    return {"PRIVATE-TOKEN": credentials.secret("GITLAB_TOKEN")}

BRANCH = "main"

@on_event
def handle(event):
    body = event.json
    p = body.get("object_attributes", {})
    if body.get("object_kind") != "pipeline" or p.get("status") != "failed" or p.get("ref") != BRANCH:
        return {"skipped": True}
    project = body["project"]
    jobs = http.get(f"{GITLAB}/projects/{project['id']}/pipelines/{p['id']}/jobs",
                    headers=gl_headers(), params={"scope": "failed"}).json()
    lines = [f"- {j['stage']}: {j['name']}" for j in jobs]
    notify.email_me(f"Pipeline failed on {project['path_with_namespace']}@{BRANCH}",
                    "\n".join(lines) + f"\n\n{project['web_url']}/-/pipelines/{p['id']}")
    return {"failed_jobs": len(jobs)}

FAQ

Common questions

Which GitLab event does it use?

A pipeline event webhook, which GitLab sends when a pipeline's status changes. You add the webhook URL under the project's integrations, and the failure notification is sent when that status becomes failed. It reacts immediately instead of polling.

Can I watch several branches?

Yes. List each branch, for example main and release, and failures on any of them are announced. Other branches are ignored, so merge request pipelines on short-lived branches do not create messages. Release branches are common additions.

Where can the notification be sent?

Most teams use Slack or email, and both can be used together. The message includes the pipeline link, branch, commit author and failed job names, so people can act without opening GitLab first. You may also page on-call if failures persist.

What permissions does it need?

read_api. Nothing else in your accounts is used.

Does it need AI?

No. It runs without AI, so it doesn't use your plan's AI allowance.

How many runs does it use?

One run for each event the app sends.

Can I change how it works?

Yes. Describe the change to your AI assistant, for example a different schedule, channel or filter. It updates the automation, tests it and tells you what changed.

The moment it happens