Matched signals
- Agent.*is offline
- Connection was broken
- Remoting connection closed
- Channel is already closed
- java.io.IOException: remoting
- No such slave/agent
- Node .* was taken offline
- SSH Connection timeout
Jenkins build agent went offline during job
What this failure means
The Jenkins build agent disconnected or went offline while running a job. The build was lost mid-execution and Jenkins cannot continue until the agent reconnects or the job is rescheduled on another agent.
Symptoms
Faultline looks for one or more of these log fragments:
Agent.*is offline
Connection was broken
Remoting connection closed
Channel is already closed
java.io.IOException: remoting
No such slave/agent
Node .* was taken offline
SSH Connection timeout
Diagnosis
Jenkins distributes work to agents (nodes). When an agent loses its connection to the controller during a build:
- The build log shows
Agent [name] is offlineorConnection was broken. - The build status shows as aborted or with a non-zero exit.
SSH Connection timeout,Remoting connection closed, orjava.io.IOException: remotingappear in the log.- Docker-based agents may exit because the container or sidecar was killed by the container runtime.
- Network interruptions, JVM crashes, OOM kills on the agent, or resource limit changes on the agent host cause disconnects.
Fix steps
-
Check Jenkins Controller → Manage Jenkins → Nodes → [agent name] for the last disconnect reason.
-
Review the agent log for the disconnect reason:
journalctl -u jenkins-agent -n 100 # or check the remoting.log on the agent host -
If the agent was OOM-killed, increase the JVM heap on the agent or reduce concurrent job parallelism.
-
For SSH agents, verify the SSH key is still valid and the controller can reach the agent host:
ssh -i ~/.ssh/jenkins_key user@agent-host "java -version" -
For Docker-based agents (Kubernetes or Docker plugin), confirm the pod/container has adequate resources and a stable network path to the controller.
-
Retry the build after the agent reconnects. If it fails repeatedly, investigate the agent host’s resource and network health.
Validation
- The agent shows as online in Jenkins → Manage Jenkins → Nodes.
- A re-triggered build completes without an agent disconnect error.
Why it matters
Jenkins agent disconnections cause immediate job loss — there is no mid-build checkpoint. Flapping agents can trigger cascading failures across all jobs routed to that agent, stopping deployment pipelines without a clear application error.
Prevention
- Monitor agent JVM memory and GC pressure; set
-Xmxlimits that leave headroom on the host. - Configure a reconnect retry window in Jenkins agent settings.
- Use pod templates with resource requests and limits when running agents in Kubernetes.
- Route critical pipelines to labeled, dedicated agents so a single flapping agent cannot block unrelated work.
- Set up agent health pings and alert on repeated disconnects before they affect user-visible pipelines.
Try it locally
curl -s http://jenkins:8080/computer/api/json | python3 -m json.tool
curl -s http://jenkins:8080/computer/api/json | python3 -m json.tool
How Faultline detects it
Use faultline explain jenkins-agent-offline to see the full playbook.
faultline analyze build.log
faultline explain jenkins-agent-offline
Generated from playbooks/bundled/log/ci/jenkins-agent-offline.yaml. Do not edit directly.