top of page

Introducing Build Intelligence in BuildNinja: Know Why Your Build Failed

3 days ago
5 min read

No more 4,000-line log hunts or guessing at pipelines you didn't write. Powered by kenzoAI, available today.

A red build tells you that something broke. It rarely tells you why.

The fix is often one line: a missing SDK, a wrong path, or a variable nobody set. Finding that line is the slow part. You scroll a long log, open a configuration someone else wrote, and check what changed since the last green build.

Today we're launching Build Intelligence in BuildNinja. It reads your build's code changes, logs, and configuration and explains what happened and what to check next, right where you already work.

A failed build, the likely cause, a follow-up question, and a risk check on the next change.

AI Runner: Risk Checks Before the Build

Most troubleshooting starts after the build is already red. The AI Runner step moves part of that work earlier.

Add AI Runner to a configuration and it reviews the code diffs behind each build. The AI Build Analysis Report shows a failure-risk score, issues by severity, and file-level findings with the problem code next to a suggested solution.

You decide how strict it is. The Failure Percentage Threshold sets the risk level that fails the step, and Continue on Server Error decides whether the step fails or the build continues when kenzoAI returns a server error.

Set it up once. Every build receives a risk score and the exact lines worth a second look.

Log Analysis

Open a failed build and click Analyze Logs. kenzoAI reads the log and returns a short summary, findings ranked by severity, and suggested fixes.

Here is a real pattern. The build dies with exit code 127. The log analysis names the cause in one line: the .NET CLI is not available on the build agent. It suggests installing the SDK and adding dotnet --info before the build as a quick check.

Exit code 127, explained in one sentence, with two concrete fixes.

Configuration Explanations

Not every failure starts in the code. A configuration can be valid and still do something nobody expected.

Explain Config walks through a build configuration step by step: what runs, what is disabled, and what makes the build pass or fail. It is helpful when something breaks, and it is equally important to understand before you change a pipeline that you did not write.

A configuration read back in plain English, including a step that is disabled and will not run.

AI Side Panel

The first answer is rarely the last question. Why was this file flagged? What should I check first? Could the configuration be the cause?

The AI Side Panel opens beside the build you are looking at, already scoped to it. Ask a follow-up and the answer builds on the analysis you already have. No new tab, no copying logs, no re-explaining your pipeline.

The side panel knows which build you are on.

Powered by kenzoAI

Every one of these capabilities runs on kenzoAI, a hosted AI service that works from your build's context.

A chatbot only knows what you paste into it. It does not know your configuration, which steps are disabled, or what changed, so you explain your pipeline from scratch every time. kenzoAI starts from the build itself. Each capability sends the context that fits its job, and kenzoAI returns findings you can check and act on.

Four capabilities, each with its own context. One intelligence layer, signed in with your application's App Key and App Secret.

Quality Settings

Not every question needs the same depth. Every request can use one of three settings. All three work with every BuildNinja AI feature; they change the depth of analysis and the credits used, not what you can do.

Setting

Credit use

Best for

Economy

Lowest

Routine log questions, quick configuration checks, short follow-ups

Optimized (recommended)

Moderate

Everyday investigations

Best

Highest

Complex failures, larger context, detailed code-change review

kenzoAI has been tested across more than 1,000 representative CI/CD evaluation runs covering build logs, configuration questions, and code-change analysis. The evaluations check how useful each answer is, how well it is backed by evidence, and how it handles cases where it is unsure.

kenzoAI Developer Portal

Admins manage kenzoAI access, credits, and usage in the kenzoAI Developer Portal.

  • Applications are the connection point. Each one has an App Key and an App Secret. The secret is shown once and can be regenerated. Keep both out of source repositories and client-side code.

  • Credit controls let you cap each application and reset its allowance manually, daily, weekly, or monthly.

  • Usage analytics show requests, sessions, and credits consumed, down to individual requests by task type and quality setting.

Account overview, per-application limits, and request-level usage in one place.

Availability and Pricing

Build Intelligence is available today in the BuildNinja Growth and Shogun editions, and you can try it without any setup in Dojo.

kenzoAI uses prepaid credits. No subscription and no per-seat AI fee. If usage goes over your balance, the overage is deducted when a new credit pack is added.

Eligible new GrapeHub accounts receive a one-time grant of 500,000 free credits when the account is created, with no payment card required. After that, top up as you go:

Pack

Credits

Per million

Config explanations

Build-risk analyses

Build-log analyses

Free grant

500,000

Free

about 40

about 8

about 50

$10

2.5 million

$4.00

about 200

about 45

about 250

$25

7 million

about $3.57

about 600

about 130

about 750

$50

15 million

about $3.33

about 1,300

about 290

about 1,600

Usage counts are estimates at the Optimized setting. Each column is an alternative use of the full balance, not a total. Actual use depends on log length, configuration size, context, and the response. Purchased credits are valid for 12 months and do not renew automatically. Prices are in USD before applicable taxes. For larger volumes, talk to us about a custom credit allocation.

Limitations and Data Handling

AI responses can be incomplete or wrong. Builds have edge cases, custom tooling, and project conventions that may not be in the context kenzoAI sees, so review a finding before you act on it. Each finding shows what it is based on, and BuildNinja AI never changes your pipeline on its own.

To produce a finding, BuildNinja sends the relevant build context (logs, configuration, or code changes) to kenzoAI. The AI data policy explains how it is handled.

Get Started

  1. Create an application in the kenzoAI Developer Portal and save its App Key and App Secret.

  2. An administrator adds them in BuildNinja under Settings → AI Configurations for log analysis, Explain Config, and the AI Side Panel. The AI Runner step takes its own App Key and App Secret in the build configuration. See Managing kenzoAI access.

  3. Open a failed build and click Analyze Logs.

Rather explore first? Try BuildNinja AI in Dojo. Its shared AI allowance does not use your credits.

Documentation

Comments


bottom of page