Skip to main content
In this lesson we demonstrate an Argo Workflows exit handler using a compact example. Exit handlers run once at the end of a workflow regardless of success or failure and are ideal for cleanup, notifications, or posting results to external systems. This behavior is analogous to Jenkins pipelines’ post { always { ... } } block. Below is a minimal workflow that shows an onExit handler named cleanup. The primary work deliberately fails (exit code 1) so you can verify the exit handler still executes.
Use onExit to centralize cleanup and notification logic. Inspect {{workflow.status}} to run conditional actions (for example, send alerts on Failure or perform extra validation on Succeeded).

​
What each template does

Explanation:
  • entrypoint: main — workflow starts at the main template.
  • onExit: cleanup — ensures the cleanup template runs when the workflow finishes, irrespective of success or failure.
  • do-work — the container task that demonstrates a failing step.
  • cleanup — exit handler that reads {{workflow.status}} and conditionally performs actions.

​
Viewing results

Even when a step fails, the exit handler still runs. In the Argo UI you can see the failed work step and the exit-handler node (typically displayed in green to indicate it completed). The screenshot below shows the failed work step and the exit-handler node along with pod details.
A screenshot of the Argo Workflows web UI showing a vertical workflow graph with a red failed "work" step and a green exit-handler node. The right-hand summary panel lists pod details including a "Failed" phase and an error message with an exit code.
Sample cleanup logs printed after the workflow fails:
You can replace the echo commands with real integrations: Slack notifications, posting status to a webhook, cleaning up cloud resources, or triggering recovery workflows. When designing critical cleanup actions, make them idempotent so repeated runs are safe.
Although onExit executes in normal success and failure scenarios, extreme outages (for example: controller crashes, severe cluster failures, or lost persistence) may prevent the exit handler from running. For critical cleanup, combine onExit with idempotent design or external watchdog processes.

​
Practical tips

  • Test exit handlers by forcing failures (exit codes) or injecting errors to ensure notifications and cleanups behave as expected.
  • Use {{workflow.status}}, {{workflow.name}}, and other workflow variables to include contextual details in alerts.
  • Keep exit handlers small and focused; offload heavy or long-running recovery tasks to separate workflows or jobs to avoid unexpected interactions.

​
References

Watch Video