Real-life DevOps
Making Jenkins Logs Usable
Reducing the distance from failure to action.
Did you know Jenkins gives you a full console log for every job it runs?
You probably did.
Now let me ask you something.
When a build fails, do you actually read it?
This starts like a lot of things do.
I was staring at a build log the other day.
Broken.
Red text everywhere.
Thousands of lines.
So I did what most of us do.
Scrolled a bit.
Searched for "ERROR" and "FAIL."
Scrolled some more.
Stopped.
Looked at it. Then got up and got more coffee.
Considered rerunning it instead.
But the truth is, when a Jenkins build fails, the information you need is usually already there.
It's just buried.
Let's dig that out.
So I copied and pasted the log into ChatGPT and asked for an analysis.
Which, let's be honest, isn't exactly rare these days.
A lot of engineers already do some version of that now. Stack Overflow and Reddit used to be where we dumped our problems. Now it's just as likely to be an AI prompt.
And it worked.
It came back with something that pointed me in the right direction. I fixed the issues, and then the pipeline failed one more time.
More specifically, though, the next iteration was done. Fixed. Fini.
Then, while I was getting more coffee, and the way all great ideas seem to show up, I asked myself:
"Instead of asking people to read the logs first, can I have AI read them first?"
So I rigged up something simple. For failed builds, I just had AI:
- pull the log
- look for the problems
- point to the lines that matter
- suggest a few next steps
It's not magic.
It's not always right. The prompts and inputs can get better. The responses can be tuned to be more accurate.
And it doesn't replace knowing what you're doing.
But it does something useful.
It gets you pointed in the right direction faster.
That's the part that stuck with me.
Nothing else changed.
Not Jenkins.
Not the logs.
Not the pipeline.
Just the connection.
I built a small example.
Same pipeline.
Same failure.
Same prompt.
Two different AI APIs.
Two different responses.
One a little tighter.
One a little more conversational.
Both useful.
But that wasn't the interesting part.
The interesting part was how quickly things shifted.
From: something broke
To: oh....there it is
And that's really the story here.
That gap.
That moment between not knowing and knowing.
That's where the friction lives.
This doesn't remove the logs.
Doesn't replace debugging.
Doesn't do the work for you.
It just shortens the distance between:
failure → understanding → action
Reducing friction.
And in a real system, that matters.
A lot more than most people think.
I wrote up exactly how I set this up.
Step by step.
No shortcuts. No magic.
A little bit of a bull in a China shop, if I'm being honest.
But it works.
If you've ever stared at a Jenkins log wondering where to even start, this might help.
For anyone who wants the nuts and bolts, I wrote up exactly how I set this up. No magic. No hype. Just the bull in a China shop version that actually works.
I also wrote a companion for Github Actions: