diff --git a/CHANGELOG.md b/CHANGELOG.md
index ef1e1aa7b..619dba3f9 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,13 @@
 # Unreleased
 
+* Update the bundler discovery section to let the `sed` command work with modern macs (issue #1371)
+* Add config for `post` scripts on both deploy and rollback sections to run `on_error`
+* Updated the code to allow for post scripts to run on command errors
+* Added extra env config (FAILED/FAILURE_MESSAGE) for use in pre-/post-scripts
+* Updated README to include `dependencies.bundler.frozen`
+* Updated README to include sections on post scripts with on_error flag
+* Refactored README to use mostly pure markdown instead of HTML
+
 # 0.42.1
 
 * Fix unbounded memory usage in RefreshCheckRunsJob(#1436)
diff --git a/README.md b/README.md
index 6f7df0e94..c77135a55 100644
--- a/README.md
+++ b/README.md
@@ -4,73 +4,73 @@
 
 **Shipit** is a deployment tool that makes shipping code better for everyone. It's especially great for large teams of developers and designers who work together to build and deploy GitHub repos. You can use it to:
 
-* add new applications to your deployment environment without having to change core configuration files repeatedly — `shipit.yml` is basically plug and play
-* control the pace of development by pushing, locking, and rolling back deploys from within Shipit
-* enforce checklists and provide monitoring right at the point of deployment.
+* Add new applications to your deployment environment without having to change core configuration files repeatedly — `shipit.yml` is basically plug and play
+* Control the pace of development by pushing, locking, and rolling back deploys from within Shipit
+* Enforce checklists and provide monitoring right at the point of deployment.
 
 Shipit is compatible with just about anything that you can deploy using a script. It natively detects stacks using [bundler](http://bundler.io/) and [Capistrano](http://capistranorb.com/), and it has tools that make it easy to deploy to [Heroku](https://www.heroku.com/) or [RubyGems](https://rubygems.org/). At Shopify, we've used Shipit to synchronize and deploy hundreds of projects across dozens of teams, using Python, Rails, RubyGems, Java, and Go.
 
 This guide aims to help you [set up](#installation-and-setup), [use](#using-shipit), and [understand](#reference) Shipit.
 
-*Shipit requires a database (MySQL, PostgreSQL or SQLite3), redis, and Ruby 2.6 or superior.*
+*Shipit requires a database (MySQL, PostgreSQL or SQLite3), Redis, and Ruby 2.6 or superior.*
 
 * * *
-<h2 id="toc">Table of contents</h2>
+## Table of contents
 
-**I. INSTALLATION & SETUP**
+### I. INSTALLATION & SETUP
 
 * [Installation](#installation)
 * [Updating an existing installation](#updating-shipit)
 
-**II. USING SHIPIT**
+### II. USING SHIPIT
 
 * [Adding stacks](#adding-stacks)
 * [Working on stacks](#working-on-stacks)
 * [Configuring stacks](#configuring-stacks)
 
-**III. REFERENCE**
+### III. REFERENCE
 
 * [Format and content of shipit.yml](#configuring-shipit)
 * [Script parameters](#script-parameters)
 * [Configuring providers](#configuring-providers)
 * [Free samples](/examples/shipit.yml)
 
-**IV. INTEGRATING**
+### IV. INTEGRATING
 
 * [Registering webhooks](#integrating-webhooks)
 
-**V. CONTRIBUTING**
+### V. CONTRIBUTING
 
 * [Instructions](#contributing-instructions)
 * [Local development](#contributing-local-dev)
 
 * * *
 
-<h2 id="installation-and-setup">I. INSTALLATION & SETUP</h2>
+## I. INSTALLATION & SETUP {#installation-and-setup}
 
-<h3 id="installation">Installation</h3>
+### Installation
 
 To create a new Shipit installation you can follow the [setup guide](docs/setup.md).
 
-<h3 id="updating-shipit">Updating an existing installation</h3>
+### Updating an existing installation {#updating-shipit}
 
 1. If you locked the gem to a specific version in your Gemfile, update it there.
 2. Update the `shipit-engine` gem with `bundle update shipit-engine`.
 3. Install new migrations with `rake shipit:install:migrations db:migrate`.
 
-<h3 id="special-update">Specific updates requiring more steps</h3>
+### Specific updates requiring more steps {#special-update}
 
 If you are upgrading from `0.21` or older, you will have to update the configuration. Please follow [the dedicated upgrade guide](docs/updates/0.22.md)
 
 * * *
 
-<h2 id="using-shipit">II. USING SHIPIT</h2>
+## II. USING SHIPIT {#using-shipit}
 
 The main workflows in Shipit are [adding stacks](#adding-stacks), [working on stacks](#working-on-stacks), and [configuring stacks](#configuring-stacks).
 
 A **stack** is composed of a GitHub repository, a branch, and a deployment environment. Shipit tracks the commits made to the branch, and then displays them in the stack overview. From there, you can deploy the branch to whatever environment you've chosen (some typical environments include *production*, *staging*, *performance*, etc.).
 
-<h3 id="adding-stacks">Add a new stack</h3>
+### Add a new stack {#adding-stacks}
 
 1. From the main page in Shipit, click **Add a stack**.
 2. On the **Create a stack** page, enter the required information:
@@ -80,7 +80,7 @@ A **stack** is composed of a GitHub repository, a branch, and a deployment envir
     * Deploy URL
 3. When you're finished, click **Create stack**.
 
-<h3 id="working-on-stacks">Work on an existing stack</h3>
+### Work on an existing stack {#working-on-stacks}
 
 1. If you want to browse the list of available stacks, click **Show all stacks** on the main page in Shipit. If you know the name of the stack you're looking for, enter it in the search field.
 2. Click the name of the stack you want to open.
@@ -93,9 +93,7 @@ A **stack** is composed of a GitHub repository, a branch, and a deployment envir
 4. When you're ready to deploy an undeployed commit, click the relevant **Deploy** button on the stack's overview page.
 5. From the **Deploy** page, complete the checklist, then click **Create deploy**.
 
-
-
-<h3 id="configuring-stacks">Edit stack settings</h3>
+### Edit stack settings {#configuring-stacks}
 
 To edit a stack's settings, open the stack in Shipit, then click the gear icon in the page header.
 
@@ -109,9 +107,9 @@ From a stack's **Settings** page, you can:
 
 * * *
 
-<h2 id="reference">III. REFERENCE</h2>
+## III. REFERENCE {#reference}
 
-<h3 id="configuring-shipit">Configuring <code>shipit.yml</code></h3>
+### Configuring `shipit.yml` {#configuring-shipit}
 
 The settings in the `shipit.yml` file relate to the different things you can do with Shipit:
 
@@ -137,36 +135,36 @@ Lastly, if you override the `app_name` configuration in your Shipit deployment,
 
 * * *
 
-<h3 id="respecting-bare-files">Respecting bare <code>shipit.yml</code> files</h3>
+### Respecting bare `shipit.yml` files {#respecting-bare-files}
 
-Shipit will, by default, respect the "bare" <code>shipit.yml</code> file as a fallback option if no more specifically-named file exists (such as <code>shipit.staging.yml</code>).
+Shipit will, by default, respect the "bare" `shipit.yml` file as a fallback option if no more specifically-named file exists (such as `shipit.staging.yml`).
 
-You can configure this behavior via the attribute <code>Shipit.respect_bare_shipit_file</code>.
+You can configure this behaviour via the attribute `Shipit.respect_bare_shipit_file`.
 
-- The value <code>false</code> will disable this behavior and instead cause Shipit to emit an error upon deploy if Shipit cannot find a more specifically-named file.
-- Setting this attribute to any other value (**including <code>nil</code>**), or not setting this attribute, will cause Shipit to use the default behavior of respecting bare <code>shipit.yml</code> files.
+* The value `false` will disable this behaviour and instead cause Shipit to emit an error upon deploy if Shipit cannot find a more specifically-named file.
+* Setting this attribute to any other value (**including `nil`**), or not setting this attribute, will cause Shipit to use the default behaviour of respecting bare `shipit.yml` files.
 
-You can determine if Shipit is configured to respect bare files using <code>Shipit.respect_bare_shipit_file?</code>.
+You can determine if Shipit is configured to respect bare files using `Shipit.respect_bare_shipit_file?`.
 
 * * *
 
-<h3 id="installing-dependencies">Installing dependencies</h3>
+### Installing dependencies
 
-The **<code>dependencies</code>** step allows you to install all the packages your deploy script needs.
+The **`dependencies`** step allows you to install all the packages your deploy script needs.
 
-<h4 id="bundler-support">Bundler</h4>
+#### Bundler {#bundler-support}
 
 If your application uses Bundler, Shipit will detect it automatically and take care of the `bundle install` and prefix your commands with `bundle exec`.
 
 By default, the following gem groups will be ignored:
 
-  - `default`
-  - `production`
-  - `development`
-  - `test`
-  - `staging`
-  - `benchmark`
-  - `debug`
+  * `default`
+  * `production`
+  * `development`
+  * `test`
+  * `staging`
+  * `benchmark`
+  * `debug`
 
 The gems you need in order to deploy should be in a different group, such as `deploy`.
 
@@ -181,7 +179,7 @@ dependencies:
       - debug
 ```
 
-<h4 id="other-dependencies">Other dependencies</h4>
+#### Other dependencies
 
 If your deploy script uses another tool to install dependencies, you can install them manually via `dependencies.override`:
 
@@ -191,7 +189,8 @@ dependencies:
     - npm install
 ```
 
-**<code>dependencies.pre</code>** If you wish to execute commands before Shipit installs the dependencies, you can specify them here.
+
+**`dependencies.pre`** If you wish to execute commands before Shipit installs the dependencies, you can specify them here.
 
 For example:
 
@@ -201,9 +200,20 @@ dependencies:
     - mkdir tmp/
     - cp -R /var/cache/ tmp/cache
 ```
-<br>
 
-**<code>dependencies.post</code>** If you wish to execute commands after Shipit installed the dependencies, you can specify them here:
+
+**`dependencies.bundler.frozen`** If you wish to execute your bundle, for the **deploy** group, without the frozen flag:
+
+For example:
+
+```yml
+dependencies:
+  bundler:
+    frozen: false
+```
+
+
+**`dependencies.post`** If you wish to execute commands after Shipit installed the dependencies, you can specify them here:
 
 For example:
 
@@ -212,14 +222,12 @@ dependencies:
   post:
     - cp -R tmp/cache /var/cache/
 ```
-<br>
-
 
-<h3 id="deployment">Deployment</h3>
+### Deployment
 
 The `deploy` and `rollback` sections are the core of Shipit:
 
-**<code>deploy.override</code>** contains an array of the shell commands required to deploy the application. Shipit will try to infer it from the repository structure, but you can change the default inference.
+**`deploy.override`** contains an array of the shell commands required to deploy the application. Shipit will try to infer it from the repository structure, but you can change the default inference.
 
 For example:
 
@@ -228,9 +236,9 @@ deploy:
   override:
     - ./script/deploy
 ```
-<br>
 
-**<code>deploy.pre</code>** If you wish to execute commands before Shipit executes your deploy script, you can specify them here.
+
+**`deploy.pre`** If you wish to execute commands before Shipit executes your deploy script, you can specify them here.
 
 For example:
 
@@ -239,9 +247,9 @@ deploy:
   pre:
     - ./script/notify_deploy_start
 ```
-<br>
 
-**<code>deploy.post</code>** If you wish to execute commands after Shipit executed your deploy script, you can specify them here.
+
+**`deploy.post`** If you wish to execute commands after Shipit executed your deploy script, you can specify them here.
 
 For example:
 
@@ -250,12 +258,31 @@ deploy:
   post:
     - ./script/notify_deploy_end
 ```
-<br>
+
+
+If you would like the post script to run even on error, you can pass the following option:
+
+```yml
+deploy:
+  post:
+    - ./script/notify_deploy_end: { on_error: true }
+```
+
+Or
+
+```yml
+deploy:
+  post:
+    - ./script/notify_deploy_end:
+        on_error: true
+```
+
+This option can come in handy when you are tracking deployment externally. The default behaviour will not run the post script.
 
 
 You can also accept custom environment variables defined by the user that triggers the deploy:
 
-**<code>deploy.variables</code>** contains an array of variable definitions.
+**`deploy.variables`** contains an array of variable definitions.
 
 For example:
 
@@ -267,9 +294,9 @@ deploy:
       title: Run database migrations on deploy
       default: 1
 ```
-<br>
 
-**<code>deploy.variables.select</code>** will turn the input into a `<select>` of values.
+
+**`deploy.variables.select`** will turn the input into a `<select>` of values.
 
 For example:
 
@@ -284,14 +311,14 @@ deploy:
         - west
         - north
 ```
-<br>
 
-**<code>deploy.max_commits</code>** defines the maximum number of commits that should be shipped per deploy. Defaults to `8` if no value is provided.
 
-To disable this limit, you can use use an explicit null value: `max_commits: null`. Continuous Delivery will then deploy any number of commits.
+**`deploy.max_commits`** defines the maximum number of commits that should be shipped per deploy. Defaults to `8` if no value is provided.
+
+To disable this limit, you can use an explicit null value: `max_commits: null`. Continuous Delivery will then deploy any number of commits.
 
 Human users will be warned that they are not respecting the recommendation, but allowed to continue.
-However continuous delivery will respect this limit. If there is no deployable commits in this range, a human intervention will be required.
+However, continuous delivery will respect this limit. If there is no deployable commits in this range, a human intervention will be required.
 
 For example:
 
@@ -299,9 +326,9 @@ For example:
 deploy:
   max_commits: 5
 ```
-<br>
 
-**<code>deploy.interval</code>** defines the interval between the end of a deploy and the next deploy, when continuous delivery is enabled. You can use s, m, h, d as units for seconds, minutes, hours, and days. Defaults to 0, which means a new deploy will start as soon as the current one finishes.
+
+**`deploy.interval`** defines the interval between the end of a deploy and the next deploy, when continuous delivery is enabled. You can use s, m, h, d as units for seconds, minutes, hours, and days. Defaults to 0, which means a new deploy will start as soon as the current one finishes.
 
 For example, this will wait 5 minutes after the end of a deploy before starting a new one:
 
@@ -310,7 +337,8 @@ deploy:
   interval: 5m
 ```
 
-**<code>deploy.retries</code>** enables retries for a stack, and defines the maximum amount of times that Shipit will retry a deploy that finished with a `failed`, `error` or `timedout` status.
+
+**`deploy.retries`** enables retries for a stack, and defines the maximum amount of times that Shipit will retry a deploy that finished with a `failed`, `error` or `timedout` status.
 
 For example, this will retry a deploy twice if it fails.
 
@@ -319,7 +347,8 @@ deploy:
   retries: 2
 ```
 
-**<code>rollback.override</code>** contains an array of the shell commands required to rollback the application to a previous state. Shipit will try to infer it from the repository structure, but you can change the default inference. This key defaults to `disabled` unless Capistrano is detected.
+
+**`rollback.override`** contains an array of the shell commands required to rollback the application to a previous state. Shipit will try to infer it from the repository structure, but you can change the default inference. This key defaults to `disabled` unless Capistrano is detected.
 
 For example:
 
@@ -328,9 +357,9 @@ rollback:
   override:
     - ./script/rollback
 ```
-<br>
 
-**<code>rollback.pre</code>** If you wish to execute commands before Shipit executes your rollback script, you can specify them here:
+
+**`rollback.pre`** If you wish to execute commands before Shipit executes your rollback script, you can specify them here:
 
 For example:
 
@@ -339,9 +368,9 @@ rollback:
   pre:
     - ./script/notify_rollback_start
 ```
-<br>
 
-**<code>rollback.post</code>** If you wish to execute commands after Shipit executed your rollback script, you can specify them here:
+
+**`rollback.post`** If you wish to execute commands after Shipit executed your rollback script, you can specify them here:
 
 For example:
 
@@ -350,7 +379,6 @@ rollback:
   post:
     - ./script/notify_rollback_end
 ```
-<br>
 
 You can also accept custom environment variables defined by the user that triggers the rollback:
 
@@ -385,7 +413,7 @@ rollback:
 ```
 <br>
 
-**<code>fetch</code>** contains an array of the shell commands that Shipit executes to check the revision of the currently-deployed version. This key defaults to `disabled`.
+**`fetch`** contains an array of the shell commands that Shipit executes to check the revision of the currently-deployed version. This key defaults to `disabled`.
 
 For example:
 ```yml
@@ -393,13 +421,14 @@ fetch:
   curl --silent https://app.example.com/services/ping/version
 ```
 
-**Note:** Currently, deployments in emergency mode are configured to occur concurrently via [the `build_deploy` method](https://github.com/Shopify/shipit-engine/blob/main/app/models/shipit/stack.rb),
+> [!NOTE]
+> Currently, deployments in emergency mode are configured to occur concurrently via [the `build_deploy` method](https://github.com/Shopify/shipit-engine/blob/main/app/models/shipit/stack.rb),
 whose `allow_concurrency` keyword argument defaults to `force`, where `force` is true when emergency mode is enabled.
 If you'd like to separate these two from one another, override this method as desired in your service.
 
-<h3 id="kubernetes">Kubernetes</h3>
+### Kubernetes
 
-**<code>kubernetes</code>** allows to specify a Kubernetes namespace and context to deploy to.
+**`kubernetes`** allows to specify a Kubernetes namespace and context to deploy to.
 
 For example:
 ```yml
@@ -408,11 +437,11 @@ kubernetes:
   context: tier4
 ```
 
-**<code>kubernetes.template_dir</code>** allows to specify a Kubernetes template directory. It defaults to `./config/deploy/$ENVIRONMENT`
+**`kubernetes.template_dir`** allows to specify a Kubernetes template directory. It defaults to `./config/deploy/$ENVIRONMENT`
 
-<h3 id="environment">Environment</h3>
+### Environment
 
-**<code>machine.environment</code>** contains the extra environment variables that you want to provide during task execution.
+**`machine.environment`** contains the extra environment variables that you want to provide during task execution.
 
 For example:
 ```yml
@@ -421,9 +450,9 @@ machine:
     key: val # things added as environment variables
 ```
 
-<h3 id="directory">Directory</h3>
+### Directory
 
-**<code>machine.directory</code>** specifies a subfolder in which to execute all tasks. Useful for repositories containing multiple applications or if you don't want your deploy scripts to be located at the root.
+**`machine.directory`** specifies a subfolder in which to execute all tasks. Useful for repositories containing multiple applications or if you don't want your deploy scripts to be located at the root.
 
 For example:
 ```yml
@@ -431,9 +460,9 @@ machine:
   directory: scripts/deploy/
 ```
 
-<h3 id="cleanup">Cleanup</h3>
+### Cleanup
 
-**<code>machine.cleanup</code>** specifies whether or not the deploy working directory should be cleaned up once the deploy completed. Defaults to `true`, but can be useful to disable temporarily to investigate bugs.
+**`machine.cleanup`** specifies whether or not the deploy working directory should be cleaned up once the deploy completed. Defaults to `true`, but can be useful to disable temporarily to investigate bugs.
 
 For example:
 ```yml
@@ -441,9 +470,9 @@ machine:
   cleanup: false
 ```
 
-<h3 id="ci">CI</h3>
+### CI
 
-**<code>ci.require</code>** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) you want Shipit to disallow deploys if any of them is missing on the commit being deployed.
+**`ci.require`** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) you want Shipit to disallow deploys if any of them is missing on the commit being deployed.
 
 For example:
 ```yml
@@ -452,7 +481,7 @@ ci:
     - ci/circleci
 ```
 
-**<code>ci.hide</code>** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) you want Shipit to ignore.
+**`ci.hide`** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) you want Shipit to ignore.
 
 For example:
 ```yml
@@ -461,7 +490,7 @@ ci:
     - ci/circleci
 ```
 
-**<code>ci.allow_failures</code>** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) you want to be visible but not to required for deploy.
+**`ci.allow_failures`** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) you want to be visible but not to required for deploy.
 
 For example:
 ```yml
@@ -470,7 +499,7 @@ ci:
     - ci/circleci
 ```
 
-**<code>ci.blocking</code>** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) you want to disallow deploys if any of them is missing or failing on any of the commits being deployed.
+**`ci.blocking`** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) you want to disallow deploys if any of them is missing or failing on any of the commits being deployed.
 
 For example:
 ```yml
@@ -479,13 +508,13 @@ ci:
     - soc/compliance
 ```
 
-<h3 id="merge-queue">Merge Queue</h3>
+### Merge Queue
 
-The merge queue allows developers to register pull requests which will be merged by Shipit once the stack is clear (no lock, no failing CI, no backlog). It can be enabled on a per stack basis via the settings page.
+The merge queue allows developers to register pull requests which will be merged by Shipit once the stack is clear (no lock, no failing CI, no backlog). It can be enabled on a per-stack basis via the settings page.
 
 It can be customized via several `shipit.yml` properties:
 
-**<code>merge.revalidate_after</code>** a duration after which pull requests that couldn't be merged are rejected from the queue. Defaults to unlimited.
+**`merge.revalidate_after`** a duration after which pull requests that couldn't be merged are rejected from the queue. Defaults to unlimited.
 
 For example:
 ```yml
@@ -493,7 +522,7 @@ merge:
   revalidate_after: 12m30s
 ```
 
-**<code>merge.require</code>** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) that you want Shipit to consider as failing if they aren't present on the pull request. Defaults to `ci.require` if present, or empty otherwise.
+**`merge.require`** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) that you want Shipit to consider as failing if they aren't present on the pull request. Defaults to `ci.require` if present, or empty otherwise.
 
 For example:
 ```yml
@@ -502,7 +531,7 @@ merge:
     - continuous-integration/travis-ci/push
 ```
 
-**<code>merge.ignore</code>** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) that you want Shipit not to consider when merging pull requests. Defaults to the union of `ci.allow_failures` and `ci.hide` if any is present or empty otherwise.
+**`merge.ignore`** contains an array of the [statuses context](https://docs.github.com/en/rest/reference/commits#commit-statuses) that you want Shipit not to consider when merging pull requests. Defaults to the union of `ci.allow_failures` and `ci.hide` if any is present or empty otherwise.
 
 For example:
 ```yml
@@ -511,7 +540,7 @@ merge:
     - codeclimate
 ```
 
-**<code>merge.method</code>** the [merge method](https://docs.github.com/en/rest/reference/pulls#merge-a-pull-request--parameters) to use for this stack. If it's not set the default merge method will be used. Can be either `merge`, `squash` or `rebase`.
+**`merge.method`** the [merge method](https://docs.github.com/en/rest/reference/pulls#merge-a-pull-request--parameters) to use for this stack. If it's not set the default merge method will be used. Can be either `merge`, `squash` or `rebase`.
 
 For example:
 ```yml
@@ -519,7 +548,7 @@ merge:
   method: squash
 ```
 
-**<code>merge.max_divergence.commits</code>** the maximum number of commits a pull request can be behind its merge base, after which pull requests are rejected from the merge queue.
+**`merge.max_divergence.commits`** the maximum number of commits a pull request can be behind it's merge base, after which pull requests are rejected from the merge queue.
 
 For example:
 ```yml
@@ -528,7 +557,7 @@ merge:
     commits: 50
 ```
 
-**<code>merge.max_divergence.age</code>** a duration after the commit date of the merge base, after which pull requests will be rejected from the merge queue.
+**`merge.max_divergence.age`** a duration after the commit date of the merge base, after which pull requests will be rejected from the merge queue.
 
 For example:
 ```yml
@@ -537,11 +566,11 @@ merge:
     age: 72h
 ```
 
-<h3 id="custom-tasks">Custom tasks</h3>
+### Custom tasks
 
 You can create custom tasks that users execute directly from a stack's overview page in Shipit. To create a new custom task, specify its parameters in the `tasks` section of the `shipit.yml` file. For example:
 
-**<code>tasks.restart</code>** restarts the application.
+**`tasks.restart`** restarts the application.
 
 ```yml
 tasks:
@@ -552,7 +581,7 @@ tasks:
       - ssh deploy@myserver.example.com 'touch myapp/restart.txt'
 ```
 
-By default, custom tasks are not allowed to be triggered while a deploy is running. But if it's safe for that specific task, you can change that behavior with the `allow_concurrency` attribute:
+By default, custom tasks are not allowed to be triggered while a deploy is running. But if it's safe for that specific task, you can change that behaviour with the `allow_concurrency` attribute:
 
 ```yml
 tasks:
@@ -592,11 +621,11 @@ tasks:
       - name: POD_ID
 ```
 
-<h3 id="custom-links">Custom Links</h3>
+### Custom Links
 
-You can add custom links to the header of a stacks overview page in Shipit. To create a new custom link, specify its parameters in the links section of the shipit.yml file. The link title is a humanized version of the key. For example:
+You can add custom links to the header of a stacks overview page in Shipit. To create a new custom link, specify its parameters in the `links` section of the shipit.yml file. The link title is a humanized version of the key. For example:
 
-**<code>links.monitoring_dashboard</code>** creates a link in the header of of the page titled "Monitoring dashboard"
+**`links.monitoring_dashboard`** creates a link in the header of the page titled "Monitoring dashboard"
 
 You can specify multiple custom links:
 
@@ -606,11 +635,11 @@ links:
   other_link: https://example.com/something_else.html
 ```
 
-<h3 id="review-process">Review process</h3>
+### Review process
 
 You can display review elements, such as monitoring data or a pre-deployment checklist, on the deployment page in Shipit:
 
-**<code>review.checklist</code>** contains a pre-deploy checklist that appears on the deployment page in Shipit, with each item in the checklist as a separate string in the array. It can contain `strong` and `a` HTML tags. Users cannot deploy from Shipit until they have checked each item in the checklist.
+**`review.checklist`** contains a pre-deploy checklist that appears on the deployment page in Shipit, with each item in the checklist as a separate string in the array. It can contain `strong` and `a` HTML tags. Users cannot deploy from Shipit until they have checked each item in the checklist.
 
 For example:
 
@@ -622,9 +651,8 @@ review:
     - Has the Docs team been notified of any major changes to the app?
     - Is the app stable right now?
 ```
-<br>
 
-**<code>review.monitoring</code>** contains a list of inclusions that appear on the deployment page in Shipit. Inclusions can either be images or iframes.
+**`review.monitoring`** contains a list of inclusions that appear on the deployment page in Shipit. Inclusions can either be images or iframes.
 
 For example:
 
@@ -635,9 +663,7 @@ review:
     - iframe: https://example.com/monitoring.html
 ```
 
-<br>
-
-**<code>review.checks</code>** contains a list of commands that will be executed during the pre-deploy review step.
+**`review.checks`** contains a list of commands that will be executed during the pre-deploy review step.
 Their output appears on the deployment page in Shipit, and if continuous delivery is enabled, deploys will only be triggered if those commands are successful.
 
 For example:
@@ -648,7 +674,7 @@ review:
     - bundle exec rake db:migrate:status
 ```
 
-<h3 id="inherit-from">Inherit From</h3>
+### Inherit From
 
 If the `inherit_from` key is specified, a deep-merge will be performed on the file therein, overwriting any duplicated values from the parent. Keys may be chained across files. Example:
 
@@ -679,12 +705,12 @@ machine:
     PUBLIC: false
 ```
 
-Loading 'shipit.production.yml' would result in:
+Loading `shipit.production.yml` would result in:
 ```rb
 {"machine"=>{"environment"=>{"TEST"=>true, "PUBLIC"=>true}}, "deploy"=>{"override"=>["./some_deployment_process.sh ${PUBLIC}"]}}
 ```
 
-<h3 id="shell-commands-timeout">Shell commands timeout</h3>
+### Shell commands timeout
 
 All the shell commands can take an optional `timeout` parameter. This is the value in seconds that a command can be inactive before Shipit will terminate the task.
 
@@ -706,7 +732,7 @@ See also `commands_inactivity_timeout` in `secrets.yml` for a global timeout set
 
 ***
 
-<h2 id="script-parameters">Script parameters</h2>
+## Script parameters
 
 Your deploy scripts have access to the following environment variables:
 
@@ -716,8 +742,8 @@ Your deploy scripts have access to the following environment variables:
 * `GITHUB_REPO_NAME`: Name of the GitHub repository being used for the current deploy/task.
 * `GITHUB_REPO_OWNER`: The GitHub username of the repository owner for the current deploy/task.
 * `EMAIL`: Email of the user that triggered the deploy/task (if available)
-* `ENVIRONMENT`: The stack environment (e.g `production` / `staging`)
-* `BRANCH`: The stack branch (e.g `main`)
+* `ENVIRONMENT`: The stack environment (e.g. `production` / `staging`)
+* `BRANCH`: The stack branch (e.g. `main`)
 * `LAST_DEPLOYED_SHA`: The git SHA of the last deployed commit
 * `DIFF_LINK`: URL to the diff on GitHub.
 * `TASK_ID`: ID of the task that is running
@@ -728,28 +754,34 @@ These variables are accessible only during deploys and rollback:
 
 * `REVISION`: the git SHA of the revision that must be deployed in production
 * `SHA`: alias for REVISION
+* `FAILED`: Set to `1` or `0` to show the state of the task
+* `ERROR_MESSAGE`: Contains the error when a deploy/rollback fails
 
-<h2 id="configuring-providers">Configuring providers</h2>
+The following is available when a rollback is triggered:
+
+* `ROLLBACK`: set to `1`
+
+## Configuring providers
 
 ### Heroku
 
 To use Heroku integration (`lib/snippets/push-to-heroku`), make sure that the environment has [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli) available.
 
-### Kubernetes
+### Kubernetes {#configuring-kubernetes}
 
 For Kubernetes, you have to provision Shipit environment with the following tools:
 
 * `kubectl`
 * `kubernetes-deploy` [gem](https://github.com/Shopify/kubernetes-deploy)
 
-<h2 id="integrating">IV. INTEGRATING</h2>
+## IV. INTEGRATING {#integrating}
 
-<h3 id="integrating-webhooks">Registering webhooks</h3>
+### Registering webhooks {#integrating-webhooks}
 
 Shipit handles several webhook types by default, listed in `Shipit::Wehbooks::DEFAULT_HANDLERS`, in order to implement default behaviours. Extra handler blocks can be registered via `Shipit::Webhooks.register_handler`. Valid handlers need only implement the `call` method - meaning any object which implements `call` - blocks, procs, or lambdas are valid. The webhooks controller will pass a `params` argument to the handler. Some examples:
 
 
-<h4>Registering a Plain old Ruby Object as a handler</h4>
+#### Registering a Plain old Ruby Object as a handler
 
 ```ruby
 class PullRequestHandler
@@ -761,7 +793,7 @@ end
 Shipit::Webhooks.register_handler('pull_request', PullRequestHandler)
 ```
 
-<h4>Registering a Block as a handler</h4>
+#### Registering a Block as a handler
 
 ```ruby
 Shipit::Webhooks.register_handler('pull_request') do |params|
@@ -769,27 +801,27 @@ Shipit::Webhooks.register_handler('pull_request') do |params|
 end
 ```
 
-Multiple handler blocks can be registered. If any raise errors, execution will be halted and the request will be reported failed to github.
+Multiple handler blocks can be registered. If any raise errors, execution will be halted and the request will be reported failed to GitHub.
 
-<h2 id="contributing">V. CONTRIBUTING</h2>
+## V. CONTRIBUTING {#contributing}
 
-<h3 id="contributing-instructions">Instructions</h3>
+### Instructions {#contributing-instructions}
 
-1. Fork it ( https://github.com/shopify/shipit-engine/fork )
-1. Create your feature branch (git checkout -b my-new-feature)
-1. Commit your changes (git commit -am 'Add some feature')
-1. Push to the branch (git push origin my-new-feature)
-1. Create a new Pull Request
+1. [Fork it](https://github.com/shopify/shipit-engine/fork)
+2. Create your feature branch (git checkout -b my-new-feature)
+3. Commit your changes (git commit -am 'Add some feature')
+4. Push to the branch (git push origin my-new-feature)
+5. Create a new Pull Request
 
-<h3 id="contributing-local-dev">Local development</h3>
+### Local development {#contributing-local-dev}
 
-This repository has a [test/dummy](/test/dummy) app in it which can be used for local development without having to setup a new rails application.
+This repository has a [test/dummy](/test/dummy) app in it which can be used for local development without having to set up a new Rails application.
 
 Run `./bin/bootstrap` in order to bootstrap the dummy application. The bootstrap script is going to:
 
-- Copy `config/secrets.development.example.yml` to `config/secrets.development.yml`;
-- Make sure all dependencies are installed;
-- Create and seed database (recreate database if already available);
+* Copy `config/secrets.development.example.yml` to `config/secrets.development.yml`;
+* Make sure all dependencies are installed;
+* Create and seed database (recreate database if already available);
 
 Run `./test/dummy/bin/rails server` to run the rails dummy application.
 
diff --git a/app/models/shipit/deploy_spec.rb b/app/models/shipit/deploy_spec.rb
index b9d2fec70..3b668f4dd 100644
--- a/app/models/shipit/deploy_spec.rb
+++ b/app/models/shipit/deploy_spec.rb
@@ -117,6 +117,10 @@ def deploy_steps!
       deploy_steps || cant_detect!(:deploy)
     end
 
+    def deploy_post
+      config('deploy', 'post') { [] }
+    end
+
     def deploy_variables
       Array.wrap(config('deploy', 'variables')).map(&VariableDefinition.method(:new))
     end
@@ -152,6 +156,10 @@ def retries_on_rollback
       config('rollback', 'retries') { nil }
     end
 
+    def rollback_post
+      config('rollback', 'post') { [] }
+    end
+
     def fetch_deployed_revision_steps
       config('fetch') || discover_fetch_deployed_revision_steps
     end
diff --git a/app/models/shipit/deploy_spec/bundler_discovery.rb b/app/models/shipit/deploy_spec/bundler_discovery.rb
index 0312935bc..f9d461f28 100644
--- a/app/models/shipit/deploy_spec/bundler_discovery.rb
+++ b/app/models/shipit/deploy_spec/bundler_discovery.rb
@@ -35,7 +35,7 @@ def remove_ruby_version_from_gemfile
         # Heroku apps often specify a ruby version.
         if /darwin/i.match?(RUBY_PLATFORM)
           # OSX is nitpicky about the -i.
-          %q(/usr/bin/sed -i '' '/^ruby\s/d' Gemfile)
+          "/usr/bin/sed -i '' '/^ruby /d' Gemfile"
         else
           %q(sed -i '/^ruby\s/d' Gemfile)
         end
diff --git a/app/models/shipit/rollback.rb b/app/models/shipit/rollback.rb
index 2a656e3a0..db45374c1 100644
--- a/app/models/shipit/rollback.rb
+++ b/app/models/shipit/rollback.rb
@@ -31,7 +31,7 @@ def commit_range
     end
 
     def to_partial_path
-      'deploys/deploy'
+      'shipit/deploys/deploy'
     end
 
     def report_complete!
diff --git a/app/models/shipit/task_execution_strategy/default.rb b/app/models/shipit/task_execution_strategy/default.rb
index 0b39ef0a9..bf583de1b 100644
--- a/app/models/shipit/task_execution_strategy/default.rb
+++ b/app/models/shipit/task_execution_strategy/default.rb
@@ -24,13 +24,17 @@ def run
       rescue Command::TimedOut => e
         @task.write("\n#{e.message}\n")
         @task.report_timeout!(e)
+        failure!(e)
       rescue Command::Error => e
         @task.write("\n#{e.message}\n")
         @task.report_failure!(e)
+        failure!(e)
       rescue StandardError => e
         @task.report_error!(e)
+        failure!(e)
       rescue Exception => e
         @task.report_error!(e)
+        failure!(e)
         raise
       end
 
@@ -104,6 +108,15 @@ def capture(command)
       rescue Command::Error
         false
       end
+
+      def failure!(error)
+        return unless @commands.respond_to?(:failed!)
+
+        @commands.failed!(error.message)
+        return unless @commands.respond_to?(:failure_step) && @commands.failure_step
+
+        capture!(@commands.failure_step)
+      end
     end
   end
 end
diff --git a/app/views/shipit/stacks/show.html.erb b/app/views/shipit/stacks/show.html.erb
index 35035830b..e866260a7 100644
--- a/app/views/shipit/stacks/show.html.erb
+++ b/app/views/shipit/stacks/show.html.erb
@@ -36,7 +36,7 @@
         <h2>Previous Deploys</h2>
       </header>
       <ul class="commit-list">
-        <%= render partial: 'shipit/tasks/task', collection: @tasks %>
+        <%= render @tasks %>
       </ul>
     </section>
   <% end %>
diff --git a/lib/shipit/command.rb b/lib/shipit/command.rb
index 6f5eb7455..b6ae8c4c2 100644
--- a/lib/shipit/command.rb
+++ b/lib/shipit/command.rb
@@ -26,11 +26,12 @@ def initialize(message, exit_code)
       end
     end
 
-    attr_reader :out, :chdir, :env, :args, :pid, :timeout
+    attr_reader :out, :chdir, :env, :args, :pid, :timeout, :run_on_error
 
     def initialize(*args, chdir:, default_timeout: Shipit.default_inactivity_timeout, env: {})
-      @args, options = parse_arguments(args)
-      @timeout = parse_timeout(options['timeout'] || options[:timeout]) || default_timeout
+      @args, @options = parse_arguments(args)
+      @timeout = parse_timeout(@options['timeout'] || @options[:timeout]) || default_timeout
+      @run_on_error = (@options['on_error'] || @options[:on_error]) == true
       @env = env.transform_values { |v| v&.to_s }
       @chdir = chdir.to_s
       @timed_out = false
diff --git a/lib/shipit/deploy_commands.rb b/lib/shipit/deploy_commands.rb
index aadb09486..700eba036 100644
--- a/lib/shipit/deploy_commands.rb
+++ b/lib/shipit/deploy_commands.rb
@@ -2,16 +2,36 @@
 
 module Shipit
   class DeployCommands < TaskCommands
+    def initialize(task)
+      super
+      @failed = false
+      @error_message = nil
+    end
+
     def steps
       deploy_spec.deploy_steps!
     end
 
+    def failure_step
+      return unless deploy_spec.deploy_post.present?
+
+      command = Command.new(deploy_spec.deploy_post, env:, chdir: steps_directory)
+      command if command.run_on_error
+    end
+
+    def failed!(error_message = nil)
+      @failed = true
+      @error_message = error_message
+    end
+
     def env
       commit = @task.until_commit
       super.merge(
         'SHA' => commit.sha,
         'REVISION' => commit.sha,
-        'DIFF_LINK' => diff_url
+        'DIFF_LINK' => diff_url,
+        'FAILED' => @failed ? '1' : '0',
+        'FAILURE_MESSAGE' => @error_message.to_s
       )
     end
 
diff --git a/lib/shipit/rollback_commands.rb b/lib/shipit/rollback_commands.rb
index e22cc1b53..0239668a9 100644
--- a/lib/shipit/rollback_commands.rb
+++ b/lib/shipit/rollback_commands.rb
@@ -6,6 +6,13 @@ def steps
       deploy_spec.rollback_steps!
     end
 
+    def failure_step
+      return unless deploy_spec.rollback_post.present?
+
+      command = Command.new(deploy_spec.rollback_post, env:, chdir: steps_directory)
+      command if command.run_on_error
+    end
+
     def env
       super.merge(
         'ROLLBACK' => '1'
diff --git a/test/models/deploy_spec_test.rb b/test/models/deploy_spec_test.rb
index 06c5a996d..bbc75e1ef 100644
--- a/test/models/deploy_spec_test.rb
+++ b/test/models/deploy_spec_test.rb
@@ -183,6 +183,16 @@ class DeploySpecTest < ActiveSupport::TestCase
       end
     end
 
+    test '#deploy_post returns a default value if `deploy.post` is not present' do
+      @spec.stubs(:load_config).returns('deploy' => {})
+      assert_equal [], @spec.deploy_post
+    end
+
+    test '#deploy_post returns `deploy.post` if present' do
+      @spec.stubs(:load_config).returns('deploy' => { 'post' => %w[foo bar baz] })
+      assert_equal %w[foo bar baz], @spec.deploy_post
+    end
+
     test '#retries_on_deploy returns `deploy.retries` if present' do
       @spec.stubs(:load_config).returns('deploy' => { 'retries' => 5 })
       assert_equal 5, @spec.retries_on_deploy
@@ -208,6 +218,16 @@ class DeploySpecTest < ActiveSupport::TestCase
       assert_nil @spec.retries_on_rollback
     end
 
+    test '#rollback_post returns a default value if `rollback.post` is not present' do
+      @spec.stubs(:load_config).returns('rollback' => {})
+      assert_equal [], @spec.rollback_post
+    end
+
+    test '#rollback_post returns `rollback.post` if present' do
+      @spec.stubs(:load_config).returns('rollback' => { 'post' => %w[foo bar baz] })
+      assert_equal %w[foo bar baz], @spec.rollback_post
+    end
+
     test '#rollback_steps returns `cap $ENVIRONMENT deploy:rollback` if a `Capfile` is present' do
       @spec.expects(:bundler?).returns(true).at_least_once
       @spec.expects(:capistrano?).returns(true)
diff --git a/test/unit/command_test.rb b/test/unit/command_test.rb
index 6597e0c32..19d5f5b21 100644
--- a/test/unit/command_test.rb
+++ b/test/unit/command_test.rb
@@ -124,6 +124,21 @@ class CommandTest < ActiveSupport::TestCase
       assert_equal 'timed out and terminated with INT signal', command.termination_status
     end
 
+    test 'on_error defaults to false' do
+      command = Command.new('cap $LANG deploy', chdir: '.')
+      assert_equal false, command.run_on_error
+    end
+
+    test 'accepts option for on_error behavior with symbol key' do
+      command = Command.new({ 'cap $LANG deploy' => { on_error: true } }, chdir: '.')
+      assert_equal true, command.run_on_error
+    end
+
+    test 'accepts option for on_error behavior with string key' do
+      command = Command.new({ 'cap $LANG deploy' => { 'on_error' => true } }, chdir: '.')
+      assert_equal true, command.run_on_error
+    end
+
     private
 
     def command_signaller_thread(command, signal: 'KILL')
diff --git a/test/unit/deploy_commands_test.rb b/test/unit/deploy_commands_test.rb
index 5fe8406c3..9c211f20e 100644
--- a/test/unit/deploy_commands_test.rb
+++ b/test/unit/deploy_commands_test.rb
@@ -307,6 +307,20 @@ def setup
       assert_equal @deploy.id.to_s, command.env['TASK_ID']
     end
 
+    test "#perform calls cap $environment deploy with the FAILED state in the environment" do
+      commands = @commands.perform
+      assert_equal 1, commands.length
+      command = commands.first
+      assert_equal '0', command.env['FAILED']
+    end
+
+    test "#perform calls cap $environment deploy with the FAILURE_MESSAGE in the environment" do
+      commands = @commands.perform
+      assert_equal 1, commands.length
+      command = commands.first
+      assert_equal '', command.env['FAILURE_MESSAGE']
+    end
+
     test "#perform transliterates the user name" do
       @deploy.user = User.new(login: 'Sirupsen', name: "Simon Hørup Eskildsen")
       commands = @commands.perform
@@ -390,5 +404,28 @@ def setup
       FileUtils.expects(:rm_rf).never
       @commands.clear_working_directory
     end
+
+    test "failure_step returns nil if there's no deploy_post step" do
+      @deploy_spec.stubs(:deploy_post).returns(nil)
+      assert_nil @commands.failure_step
+    end
+
+    test "failure_step returns a Command if there's a deploy_post with config to run on_error" do
+      @deploy_spec.stubs(:deploy_post).returns('echo "hello"' => { 'on_error' => true })
+      command = @commands.failure_step
+      assert_instance_of Command, command
+      assert_equal ['echo "hello"'], command.args
+    end
+
+    test "failure_step returns nil if there's no deploy_post without config to run on_error" do
+      @deploy_spec.stubs(:deploy_post).returns('echo "hello"')
+      assert_nil @commands.failure_step
+    end
+
+    test "#failed! updates the env with the FAILED and FAILURE_MESSAGE states" do
+      @commands.failed!('Deployment failed')
+      assert_equal '1', @commands.env['FAILED']
+      assert_equal 'Deployment failed', @commands.env['FAILURE_MESSAGE']
+    end
   end
 end
diff --git a/test/unit/rollback_commands_test.rb b/test/unit/rollback_commands_test.rb
index 3092e5425..3c4441718 100644
--- a/test/unit/rollback_commands_test.rb
+++ b/test/unit/rollback_commands_test.rb
@@ -33,5 +33,22 @@ def setup
       command = commands.first
       assert_equal '1', command.env['ROLLBACK']
     end
+
+    test "failure_step returns nil if there's no rollback_post step" do
+      @deploy_spec.stubs(:rollback_post).returns(nil)
+      assert_nil @commands.failure_step
+    end
+
+    test "failure_step returns a Command if there's a rollback_post with config to run on_error" do
+      @deploy_spec.stubs(:rollback_post).returns('echo "hello"' => { 'on_error' => true })
+      command = @commands.failure_step
+      assert_instance_of Command, command
+      assert_equal ['echo "hello"'], command.args
+    end
+
+    test "failure_step returns nil if there's a rollback_post without config to run on_error" do
+      @deploy_spec.stubs(:rollback_post).returns('echo "hello"')
+      assert_nil @commands.failure_step
+    end
   end
 end