Capability

Ask Jenkins what went wrong

Read jobs, builds, the queue and console logs, find out why a build failed, and trigger or stop builds with your approval.

Create account See the full flow

Jenkins controller Freestyle and pipeline jobs Multibranch pipelines Folders Build parameters Build queue Agents and nodes JUnit test results Console logs API token authentication

In your words

Ask it like this

No syntax to learn. These are real requests, phrased the way people actually phrase them.

›is anything building right now ›why did the last deploy job fail ›which tests broke in that build ›why has this build been queued for twenty minutes ›run the staging deploy with the release branch ›stop that build, it is running against the wrong branch ›is any build agent offline

Capability

What it does here

Everything below is what the agent does today, not a roadmap.

Reads job status, build history and the console log without you opening the UI
Answers why a build failed from the log, rather than telling you it failed
Shows what is queued and what is blocking it, including offline agents
Reads test results, so a red build turns into which tests broke
Triggers builds with parameters, stops a running build, cancels a queued item, each confirmed first
Takes an agent offline or back online with a reason attached

What it looks like

One question, one answer, one fix

The checks on the left of each reply are the reads it did before committing to an answer. That is the difference between a diagnosis and a guess.

Every exchange ends in a verified outcome. It goes back and confirms the result rather than assuming the fix worked.

brynko devOps Agent

why did the deploy job fail?

read job status read build #418 log read test results

Build #418 failed at the publish stage, not at the tests. The step ran docker push and got denied: requested access to the resource is denied, which is a registry credential problem rather than anything in your code. The 214 tests before it all passed.

run it again once I have fixed the token

triggered deploy queued as #419

Started. #419 is queued with the same parameters as #418 - branch main, environment staging. I will not guess at parameters, so those are the ones you had before. Ask me any time and I will tell you where it has got to.

Triggered · you approved it

Common cases

The ones that cost you an afternoon

Each of these is a specific failure with a specific set of checks behind it, not a general promise to help.

The build failed and the log is enormous

Thousands of lines, and the actual error is somewhere in the middle, usually not next to the word error.

What it does. It reads the console log and tells you which step failed and why, rather than handing you the log back with the failure still in it.

The build is queued and nothing is happening

No progress, no error, and the queue page does not explain itself.

What it does. It reads the queue and the node list together, because a stuck build is almost always an offline agent, a label with nothing matching it, or an executor that is already busy.

A test broke and nobody knows which

The build is red, the summary says failed, and finding the actual test means clicking through the report.

What it does. It reads the test results directly and names the tests that failed, so triage starts at the test rather than at the build.

Somebody needs to trigger a deploy

The person who knows the parameters is not around, and guessing them on a deploy job is how the wrong branch reaches production.

What it does. It triggers the job with the parameters you state, and shows you the job and every parameter before it starts. The approval is bound to those exact parameters, so a token for a staging deploy cannot start a production one.

The wrong thing is running right now

A build is mid-flight against the wrong branch and every minute it continues makes the cleanup worse.

What it does. It stops a running build or cancels a queued item on your say-so, which is faster than finding the job, the build number and the right button.

Jenkins is a separate world from your servers

Answering a CI question means leaving whatever you were doing, opening another tool and losing the thread.

What it does. It reaches Jenkins over its API using a saved credential, so a CI question is asked in the same conversation as the server it deploys to - and it never goes hunting for Jenkins among your servers.

Start to finish

What happens between the question and the fix

You add a Jenkins URL and API token once
Stored encrypted on your own machine. The controller is addressed by that credential, so Jenkins never has to be one of your registered servers.
You ask about a job, a build or the queue
Reads are free and need no approval - status, history, console logs, test results, nodes and the queue.
It answers from the log, not about the log
A failed build comes back as the step and the reason, not as a link to go and read it yourself.
You approve anything that changes state
Triggering a build, stopping one, cancelling a queued item or taking a node offline. The job and every parameter are shown before it runs.
The approval is bound to the controller
A confirmation is tied to the Jenkins hostname it was issued for, so an approval given against a staging controller cannot be replayed against production.

The part that matters

Reading is free. Changing asks first.

Reads run instantly and need no permission, because reading cannot break anything. Anything that changes a system, whether that is a restart, an edit, an install or a delete, stops and tells you what it is about to change, on which server, and why. You see it written out, as the command it will run or a red and green diff of the file, so you are approving the actual thing rather than a description of it. Changes are backed up first, so undoing one is a click.

Read the security model

Questions

Jenkins, specifically

Does Jenkins need to be one of my servers?

No. It is reached over the Jenkins API using a saved URL and API token, so it does not need SSH access and it is never searched for among your registered servers.

Can it start a build without asking?

No. Triggering a build is treated as a change, because a Jenkins job usually deploys something. You see the job and every parameter first, and the approval is bound to those exact parameters.

Where is my API token stored?

Encrypted at rest on your own machine and decrypted only when a call is made. It is never sent to the model.

Can it read logs from any job?

It can read what your token can read. Permissions stay with Jenkins - giving the agent a token does not widen what that token is allowed to do.

Can it stop a build that is already running?

Yes, with your approval, and it can cancel a queued item too. Both are treated as changes rather than reads.

What about build agents?

It can list nodes and tell you which are offline, which is usually the answer when a build is stuck in the queue. Taking a node offline or bringing it back needs approval, and a reason is recorded with it.

Also covered

The rest of the stack

It runs on your machine too

Build, run and fix projects on your own computer, including installing the runtime the project needs.

A real file editor for your Linux servers, no nano required

Browse your Linux servers as a file tree and edit files in a real editor with syntax highlighting, find and replace and search across the whole box. Over the SSH access you already have, with nothing installed on the server.

Know the moment a server breaks, and why

brynko pulse installed in one click: alerts within seconds by email, WhatsApp, Telegram or Slack, fixes with your approval, and an alert even when a whole server goes down.

Docker, without memorising the flags

Inspect containers, read logs, check stats, restart services and run Compose stacks, just by describing what you want.

Your reverse proxy, explained and fixed

Test configs before they go live, read the right log, and reload safely, on nginx, IIS or Tomcat.

From code to a running site, and know what shipped

It builds the deployment with you: the deploy script, Docker, nginx and pipeline files, a ready server, then the release itself, checked afterwards.

Try it on something that already annoys you

Point it at one server. You will know within an hour whether it earns its place.

Create account See pricing