Scenario triggers

Creating a trigger

Triggers allow you to define when a scenario should be executed based on certain events.

When you create or edit a scenario for an application (located in the application details screen under the Scenarios tab) you will find the Triggers section.

Types of triggers

The following triggers are available. The bold markers indicate the actual trigger.

• Start the application before the scenario runs
• stop the application after the scenario finished
• Stop the application after the scenario fails
• Execute the current scenario after the application starts
• Execute the current scenario before the application stops
• Execute another scenario after the scenario fails or succeeds

Start the application before the scenario runs

Scenarios can be scheduled or called via a webhook. It is mandatory that the application the scenario resides in is running. When you enable this trigger, the platform will launch the application to execute the scenario. You also have the option to start shared applications as well.

Stop the application after the scenario finishes

In some cases you want the application to shut down after executing the scenario. Think about nightly security updates in non production environment. Shutting the application down after scenario execution enables cost optimisation.

Stop the application after the scenario fails

If a scenario fails, instead of leaving your application running in a potentially broken or vulnerable state, you can choose to stop the application. This allows you to investigate the issue before relaunching. In the future, we will offer the possibility to trigger another scenario, such as a rollback, display a maintenance page, or restore a backup.

Execute the current scenario after the application starts

Automatically execute one or more scenarios directly after launching an app. This could include initializing environment parameters, loading configuration files, setting up dependencies, running health checks, or synchronizing data. You can set these actions in a scenario to be executed every time the app is launched.

Execute the current scenario before the application stops

The same applies to stopping an application. You can trigger scenarios when stopping the application. This might include notifying users about the shutdown, clearing caches, closing database connections, or terminating open sessions. With this trigger, you can ensure a safe shutdown tailored to your processes.

Execute another scenario after the scenario fails or succeeds

You can trigger another scenario when the current scenario fails or succeeds. This scenario can be of a different application in the same environment. Using this system, you can set up complicated multi-application logic, should the need arise. Possible use cases are to automatically execute a rollback scenario after a failed deployment scenario, or clearing a cache after a successful deploy. It can also be useful if a specific setup requires complex interdependent initialization/deployment orchestration between multiple systems.

Setting a delay

For some triggers, you have the option to set a delay. This allows the application to launch before executing the scenario or to execute the scenario before shutting down the application.

Disabling availability monitoring alerts

Your application might be unavailable when running scenarios. We recommend disabling availability monitoring alerts during scenario runs to prevent false alerts about unavailability. This can be done in the Monitoring tab within the Scenarios section.