The moment it happens

Get alerted when a pipeline run fails

A failed build on your main pipeline is posted right away, so nobody merges on top of it.

Runs: The moment it happens
Apps: Azure DevOps
AI: Not needed
Access: Build Read

Send this to your assistant

Create a ClickRuntime automation: when a build of our main-ci pipeline in Azure DevOps fails, post the pipeline name, branch and link to #builds in Slack.

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 CI pipeline fails at 6 pm on Friday and nobody notices. The developer who pushed the change has gone home, the Azure DevOps dashboard is not on anyone's screen, and the email notification from Azure goes to an inbox buried under other messages. On Monday the team discovers that the main branch has been red all weekend, three more commits landed on top of the break, and the release planned for the morning is already late.

When a pipeline run completes in Azure DevOps, a service hook sends the event to ClickRuntime. ClickRuntime reads the result, and if it is failed, posts a message to Slack with the pipeline name, the branch and a link to the run, so someone can open the logs.

Teams that rely on a broken main branch being fixed quickly use it to make failures a shared, visible event.

What you get out of it

The main branch is repaired the same day
A failure posted to a channel gets a reply within minutes. The break is fixed before more commits pile on top and make it harder to find which change caused it.
Weekend and evening failures are not missed
Scheduled and overnight pipelines fail when nobody is watching. A message in Slack reaches whoever is on call or checks the channel first thing in the morning. Someone on call or an early riser sees it first.
Responsibility becomes clear in the thread
The message names the pipeline and branch, so the person who pushed the change can say they are on it. Nobody has to ask who owns the red build. Nobody has to ask who is looking into the red build.
Releases are less likely to slip
Planned deployments depend on green builds. Knowing about a failure early gives the team time to fix it without moving the release date. Release dates move far less often when failures are known early.
Only failures create noise
Successful runs stay quiet, which means the channel stays useful. When a message appears, people know it needs attention instead of learning to ignore it. A message therefore always means something needs attention.

How it works

What happens, step by step

Each time a build finishes on your main Azure DevOps pipeline, Azure DevOps tells ClickRuntime straight away.
If the build passed, nothing happens.
If it failed, a message goes to #builds with the pipeline, branch, build number and a link to the results.

Before it runs live

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

What you get

RunsThe moment it happens

Get alerted when a pipeline run failsjust nowSucceeded

Slack · #builds:x: main-ci failed on main (20261019.3) https://dev.azure.com/acme/Phoenix/_build/results?buildId=5521

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 Azure DevOps 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.

failed_build_alert.pyexample

from clickruntime import on_event, notify

PIPELINE = "main-ci"

@on_event
def handle(event):
    body = event.json or {}
    if body.get("eventType") != "build.complete":
        return {"skipped": body.get("eventType")}
    build = body["resource"]
    if build["definition"]["name"] != PIPELINE or build.get("result") != "failed":
        return {"skipped": f"{build['definition']['name']} {build.get('result')}"}
    branch = build.get("sourceBranch", "").replace("refs/heads/", "")
    notify.slack(f":x: {PIPELINE} failed on {branch} ({build.get('buildNumber')})\n{build['_links']['web']['href']}",
                 channel="#builds")
    return {"build": build["id"]}

FAQ

Common questions

How do I connect Azure DevOps to ClickRuntime?

Azure DevOps has service hooks under project settings. You create a subscription for the event type Build completed and set the destination to a web hook URL, which your AI assistant provides. After that, each finished build sends its result to ClickRuntime.

Can I limit alerts to certain pipelines or branches?

Yes. The service hook can be filtered to specific pipelines and results when you create it, and ClickRuntime can also filter on branch name. A common choice is to alert only on failures of the main branch and release pipelines.

Does it also report partially succeeded builds?

The result field can be succeeded, partiallySucceeded, failed or canceled. By default only failed runs post. If your team treats warnings as problems, you can ask for partially succeeded builds to be included as well.

What permissions does it need?

Build Read. 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