Jenkins Declarative "post" Conditions Not Running - Fix post Blocks

A declarative post block did not run the action you expected. Either the condition (success, failure, always, unstable, cleanup) did not match the build result, the post is in the wrong place, or a step inside post failed silently.

What this error means

A cleanup or notification in post never fired (or fired at the wrong time). For example, a post { success { ... } } notification did not send because the build was UNSTABLE, not SUCCESS, so the condition did not match.

// build ended UNSTABLE (tests flaky-passed with failures)
post {
  success { slackSend message: 'Deployed' }   // did NOT run: result was UNSTABLE
}

Common causes

Condition did not match the build result

success only runs on SUCCESS, failure only on FAILURE. An UNSTABLE or ABORTED result matches neither, so a block guarded by success/failure is skipped. Use always for unconditional actions.

post placed at the wrong scope

A stage-level post {} only reflects that stage; a pipeline-level post {} reflects the whole build. Putting it at the wrong level changes which result it sees.

A step inside post failed

If a step in post throws (e.g. a notification credential missing), the post action does not complete - and a failure in post can mask why the action did not happen.

How to fix it

Use the right post conditions

Use always/cleanup for unconditional work and combine conditions to cover UNSTABLE.

post {
  always  { junit 'reports/**/*.xml' }
  success { slackSend message: 'Build OK' }
  unstable { slackSend message: 'Build UNSTABLE' }
  failure { slackSend message: 'Build FAILED' }
  cleanup { cleanWs() }
}

Place post at the right scope and guard its steps

1. Use pipeline-level post {} for whole-build outcomes, stage-level for per-stage.
2. Account for UNSTABLE/ABORTED explicitly when they matter.
3. Wrap fragile post steps so a notification failure does not hide the real result.

How to prevent it

• Use always/cleanup for actions that must always run.
• Handle UNSTABLE and ABORTED results explicitly, not just success/failure.
• Keep post steps robust so they do not fail silently.

Related guides