🚨 Jenkins Error: 'Jenkins is going to shut down' — Cause, Fix, and Troubleshooting Guide

Overview

A banner appears across every Jenkins page and new builds refuse to start, queuing up instead of running:

Jenkins is going to shut down

Despite the wording, Jenkins is usually not crashing. This is quiet mode (also called “Prepare for Shutdown”): someone — or something — put the controller into a state where it lets in-flight builds finish but blocks any new build from starting, in preparation for a safe restart or shutdown. If nobody then completes the restart, or automation left the flag set, Jenkins sits in this half-open state indefinitely, silently backing up the queue. The fix is simply to cancel quiet-down.

Symptoms

• A persistent header banner reads Jenkins is going to shut down on every page.
• New builds go to the queue with a “Jenkins is about to shut down” reason and never start.
• Currently running builds finish normally, but nothing new begins.
• The queue grows steadily while executors sit idle after current work drains.
• The state persists for hours with no actual restart happening.
• It commonly appears right after someone clicked Prepare for Shutdown, or after a safeRestart/plugin upgrade that didn’t complete.

Common Root Causes

• Someone enabled “Prepare for Shutdown” — an admin used Manage Jenkins > Prepare for Shutdown (or hit /quietDown) to drain builds before maintenance and never finished or cancelled it.
• A safeRestart / safe shutdown that stalled — safeRestart puts Jenkins in quiet mode first; if the restart was blocked (a build never finished, a plugin hung), it stays quiesced.
• Plugin or core upgrade left it quiesced — installing/updating plugins with “restart when no builds are running” enables quiet-down; if the restart never triggers, the flag sticks.
• Automation set quietDown and didn’t clear it — a maintenance script, blue/green deploy, or backup job called quiet-down (optionally with -block) and failed before calling cancel-quiet-down.
• A stuck build prevents the drain from completing — quiet mode waits for running builds; a hung, never-ending build keeps Jenkins “preparing” forever.

How to diagnose

Confirm it really is quiet mode and not a genuine shutdown. The banner plus still-running Jenkins (pages load, current builds finish) is the tell. Check the flag directly from the Script Console (Manage Jenkins > Script Console), read-only:

// true = Jenkins is in quiet-down / preparing to shut down
println "isQuietingDown = ${Jenkins.instance.isQuietingDown()}"

Check whether a stuck build is holding the drain open:

// List currently running builds that quiet mode is waiting on
Jenkins.instance.computers.each { c ->
  c.executors.each { e ->
    if (e.isBusy()) println "${c.displayName}: ${e.currentExecutable}"
  }
}

Review the audit/system log to see who or what triggered it and when:

# Look for quietDown / safeRestart / cancelQuietDown events
journalctl -u jenkins --since '1 hour ago' | grep -iE 'quiet|safeRestart|shutdown'

If you use the Audit Trail plugin, its log records the /quietDown request and the user who made it.

Fixes

Fix 1: Cancel quiet-down from the UI

The simplest fix: go to the Jenkins dashboard and click Cancel Shutdown (shown in the banner or at Manage Jenkins). This clears the flag and new builds start immediately. Equivalently, an admin can visit the endpoint:

http://jenkins.example.com/cancelQuietDown

Fix 2: Cancel via the Jenkins CLI

If the UI is inconvenient or you’re scripting recovery, use the CLI’s cancel-quiet-down:

java -jar jenkins-cli.jar -s http://jenkins.example.com/ \
  -auth <user>:<api-token> cancel-quiet-down

The inverse command, quiet-down (optionally -block / -timeout), is what puts Jenkins into this state — use it deliberately for maintenance and always pair it with cancel-quiet-down.

Fix 3: Clear the flag from the Script Console

If CLI/UI access is awkward, toggle the flag directly (this both cancels quiet-down):

// Cancels quiet mode; new builds resume
Jenkins.instance.doCancelQuietDown()
println "isQuietingDown = ${Jenkins.instance.isQuietingDown()}"

Fix 4: Finish the intended restart instead

If quiet mode was a legitimate prelude to maintenance and the drain is complete (no running builds), just complete the action — perform the safeRestart/upgrade — rather than cancelling. After the restart, Jenkins comes back with quiet mode cleared.

Fix 5: Clear a stuck build blocking the drain

If a hung build is keeping Jenkins “preparing” forever, abort that build (from its page, or the console), then cancel quiet-down. Add a timeout to the offending pipeline so a stuck stage can’t block future drains:

options { timeout(time: 60, unit: 'MINUTES') }

What to watch out for

• Read the banner literally but skeptically — “going to shut down” almost always means quiet mode, not a dying process; verify with isQuietingDown() before restarting anything.
• Any automation that calls quiet-down must call cancel-quiet-down in a finally/cleanup path, or a failure mid-maintenance leaves Jenkins quiesced.
• Plugin installs offering “restart when no builds are running” quietly enable quiet-down; make sure the restart actually completes.
• A single hung build can stall a safeRestart indefinitely — enforce build timeouts so drains can finish.
• If quiet mode reappears right after you cancel it, an automation or scheduled job is re-enabling it; find and fix that caller rather than repeatedly cancelling.
• For a fast triage of a stuck or reappearing quiet-down incident, the free incident assistant can help correlate who triggered it.

Related

• Jenkins Error: Waiting for next available executor — the other reason new builds sit in the queue instead of starting.
• Jenkins: queue item stuck — diagnosing a specific queued item that will not run.
• Jenkins Error: FATAL: command execution failed — a remoting failure that can hang a build and block a drain from completing.