The section after the action is called the postlude. The rule's postlude statement is evaluated after the action has been generated.
The postlude allows for effects. Effects are an important addition to the ECA pattern. Effects differ from actions in that they do not result in directive documents being sent to the endpoint. Instead, they cause side effects on the KRE system. Examples of effects include the following:

The rule postlude allows action to be taken based on whether or not the rule fired. The most common use is to manage persistent variables. You can also place explicit logging statements in the prelude.
Postludes are evaluated based on the status of the rule: fired, notfired, or always. The fired and notfired constructs take an optional else clause that is executed in the opposite state. Consequently, a postlude takes on of the following forms:

always {
  <postlude statement> [; <postlude statement>]*
}
fired {
  <postlude statement> [; <postlude statement>]*
} else {
  <postlude statement> [; <postlude statement>]*
}
notfired {
  <postlude statement> [; <postlude statement>]*
} else {
  <postlude statement> [; <postlude statement>]*
}

Since the else is optional, you will often see postludes without it:

fired {
  <postlude statement> [; <postlude statement>]*
} 

The following section describe the various statements that a postlude can contain: