# Create a "finalize" step type so that I can perform various types of clean up

**URL:** <https://forum.buildkite.community/t/create-a-finalize-step-type-so-that-i-can-perform-various-types-of-clean-up/1232>\
**Category:** Features Requests\
**Created:** [September 7, 2020, 3:28pm UTC](https://forum.buildkite.community/t/create-a-finalize-step-type-so-that-i-can-perform-various-types-of-clean-up/1232 "2020-09-07T15:28:52Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![clambertops](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.buildkite.community/clambertops/32/903_2.png) [@clambertops](https://forum.buildkite.community/u/clambertops)\
**Post date:** [September 7, 2020, 3:28pm UTC](https://forum.buildkite.community/t/create-a-finalize-step-type-so-that-i-can-perform-various-types-of-clean-up/1232/1 "2020-09-07T15:28:53Z")

</div>

While we have `allow_dependency_failures` and `allow_failure`, these only work on actual step failures, not on canceled steps. In other words, if one has a “clean up” step it will not run if one manually cancels a step. Presumably, one might want a finalizer to always run to clean up external resources or perform some sort of logging action (perhaps to record metrics in an external system).

I understand that utilizing external resources may be an anti-pattern, but it’s hard to avoid when dealing with backend infrastructure, distributed systems, or scale testing. It also seems trivial to add (from a conceptual and implementation perspective) by following the existing patterns: `allow_cancel` or something along those lines. (Of course, thinking about step-level vs build-level cancel operations may complicate this… I’m sure you could come up with something clean if you thought about it, though. :) )

NOTE: this likely overlaps with other topics related to cancel behavior, such as capturing the cancel status as a separate code and color (which we’re a big +1 on).