> For the complete documentation index, see [llms.txt](https://docs.steadybit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.steadybit.com/use-steadybit/experiments/run.md). # Run Once your [experiment is fully designed](/use-steadybit/experiments.md), you can use the `Run` button to execute it. This action can be performed if all the following conditions are met: 1. There are no validation errors. 2. Every attack resolves at that moment to at least one target. 3. You are a member of the same team as the experiment. 4. [Emergency stop](/use-steadybit/experiments/emergencystop.md) has not been triggered. Otherwise, you'll get an error message and the experiment is not started. ## Run View As soon as the experiment starts, the platform automatically switches over to the run view. The first step of the platform is to establish the connection to the matching agents. In addition, a running experiment is indicated by the run icon in the top right. ![Experiment Run View](https://853194531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZLJS2c8EXBcu8PiwteIJ%2Fuploads%2Fgit-blob-178cb87412374fb7afed53f1ad7f8e52bd47174e%2Frun-experiment.png?alt=media) Every experiment run has a unique identifier (e.g. **#33131**), which you can use to identify older experiment runs (visible on the left side). The run view itself consists of the following elements. * **Run Timeline**: At the top you see the sequence defined previously in the [design](/use-steadybit/experiments/design.md). While the experiment is running, a special marker indicates the current point in time. Some attacks need a little extra time before they start, which is indicated by light green coloring at the front. That extra time is added to the timing of the attack and is currently needed for technical reasons. You can click on each step to get more details in the [run modal](#run-modal). * **Run Status**: The run log lists the currently active or already performed experiment's steps. You can click on each step to get more details in the [run modal](#run-modal). * **Deployment Replica Count**: When using an experiment in a Kubernetes context we automatically monitor how many pods are ready in your cluster and indicate whenever there is a discrepancy. * **Kubernetes Event Log**: When using an experiment in a Kubernetes context we provide you access to the Kubernetes Events so that you can identify what exactly happens in the Kubernetes cluster. * **HTTP Call**: If your experiment contains an `HTTP Call` action you can see the response time as well as HTTP response status as a separate widget in the run window. * **Monitoring Events**: In case your admin has installed a monitoring extension into Steadybit (see [monitoring extensions in Reliability Hub](https://hub.steadybit.com/extensions?tags=Monitoring)) you can see occurring events and alerts of your setup directly in the run view. * **Run Analysis**: If [SteadyBuddy](/use-steadybit/steadybuddy.md) is enabled, a failed or errored run offers to explain itself — verdict, root cause, a judgment on your hypothesis, and a recommendation. See [analyze an experiment run](/use-steadybit/steadybuddy.md#analyze-an-experiment-run). ### Run Modal You can click on each experiment step in the 'run timeline'- or 'run status'-widgets to get more details. The modal allows you to see the actions' configuration, the exact timing and affected targets (e.g., containers attacked by the blackhole-attack). ![Experiment Run Modal - Attacked Targets](https://853194531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZLJS2c8EXBcu8PiwteIJ%2Fuploads%2Fgit-blob-809e79e6522f824170391c07601b155116b6d052%2Frun-experiment-modal.png?alt=media) The run modal also details more information whenever a step — and thus the experiment — has errored or failed. ![Experiment Run Modal - Failed Step](https://853194531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZLJS2c8EXBcu8PiwteIJ%2Fuploads%2Fgit-blob-dabab6bc3e2ee11488f0dbd9aea46028fe8314f8%2Frun-experiment-modal-failed.png?alt=media) #### Advanced Blast Radius Whenever you have used the [advanced blast radius](/use-steadybit/experiments/design.md#limiting-targets-via-blast-radius), you can see the picked values at the top of the run modal. ![Experiment Run Modal - Advanced Blast Radius](https://853194531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZLJS2c8EXBcu8PiwteIJ%2Fuploads%2Fgit-blob-4c36c3b3e35bf1077b7e7f7e1aca282a0cee6fb2%2Frun-experiment-modal-advanced-blast-radius.png?alt=media) ## States An experiment run has states at three different levels: * [**Experiment run**](#experiment-run) indicating an overall state of the run *(highest level)* * [**Step**](#step) each individual step performed in an experiment run * [**Target execution**](#target-execution) each individual target affected in a step *(lowest level)* The state from a lower level is propagated to the upper level, as described [below](#state-propagation). ### Experiment Run An experiment run is in one of the following states: | State | Description | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | REQUESTED | The experiment was requested by a user, an API call or a schedule. | | CREATED | The experiment was created and all targets were resolved. | | PREPARED | The experiment is prepared, all preflight checks were successful, and agents are ready to execute the needed actions. | | RUNNING | The experiment is currently running and performing actions (e.g. attacks). | | COMPLETED | The entire experiment, including all actions, was successfully executed — no failure or error reported by any step. | | CANCELED | The experiment was canceled by user interaction or system (in case of a failed validation in `REQUESTED` or `CREATED`) and all attacks were rolled back. | | FAILED | The run failed due to some failing checks, for example an *HTTP Check* not reaching the required success rate. | | ERRORED | The run errored due to some technical reasons like `I/O error on POST request: Connection refused` or `Agent disconnected unexpectedly`. This shouldn't happen frequently, in case it does, let us know. We are constantly improving the platform to reduce error states. | In case an agent loses the connection to the platform during an experiment, it immediately stops and rolls back running attacks. Some attacks (like `Stop Container`) can't be rolled back, by their very nature. ### Step Every step that is executed as part of an experiment run is in one of the following states: | State | Description | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | CREATED | All targets of the step have been resolved. | | PREPARED | Agents for all resolved targets are connected and ready to execute the step's action as soon as it's the step's turn in the designed experiment timeline. | | RUNNING | The step's action is currently executed on at least one target. Targets may start at different times, so a step becomes `RUNNING` as soon as its first target execution starts. | | COMPLETED | The step's action was successfully executed on all targets — no failure or error. | | CANCELED | The step was running before — i.e., at least one target execution had started — and has now been canceled, either by a user canceling the entire experiment run or by the system (e.g. when another step running in parallel caused the experiment to stop early). | | SKIPPED | The step's action was never executed, because the experiment was stopped before. | | FAILED | The step failed because of a failed check, such as an *HTTP Check* that did not reach the required success rate, or because it had no matching targets anymore. | | ERRORED | The step's action errored due to some technical reasons, such as `I/O error on POST request: Connection refused` or `Agent disconnected unexpectedly`. | ### Target Execution For every step, there are one or more target executions. The actual number depends on the number of targets selected in the experiment design and the nature of the step. The target executions are listed as 'selected targets' in the [run modal](#run-modal). Each target execution is in one of the following states: | State | Description | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CREATED | The target was selected to be attacked in an experiment run's step. | | PREPARED | The agent that discovered the selected target is connected. | | RUNNING | The action is currently executed on the selected target. | | COMPLETED | The action was successfully executed on the selected target — no failure or error. | | CANCELED | The action was executed before and has now been canceled on the selected target, either by a user canceling the entire experiment run or by the system (e.g. when another target execution of the same step or another step running in parallel caused the experiment to stop early). | | SKIPPED | The action was never executed on the selected target, because the experiment's step was stopped before. | | FAILED | The action performed on the selected target noticed a deviation in the check, such as an *HTTP Check* that did not reach the required success rate. | | ERRORED | The action performed on the selected target errored due to some technical reasons, such as `I/O error on POST request: Connection refused` or `Agent disconnected unexpectedly`. | ### State Propagation The different levels of states (**experiment run**, **step**, **target execution**) can be propagated to higher levels (e.g., state `FAILED` at target execution level is propagated to step being `FAILED` and experiment run being `FAILED`). They also change the states of adjacent instances at the same level (e.g., a `FAILED` step causes subsequent steps to be `SKIPPED`) and at the level below (e.g., for a `SKIPPED` step, all target executions are `SKIPPED` as well). A step and its target executions therefore always agree on whether anything was actually executed: a step is only `CANCELED` if at least one of its target executions was `RUNNING`. If none of them ever started, the step and all of its target executions are `SKIPPED` — even if the action had already been sent to the agents. #### Example: State Propagation The following example shows the state propagation in action: ![Experiment run showing state propagation](https://853194531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZLJS2c8EXBcu8PiwteIJ%2Fuploads%2Fgit-blob-a5438e74cd673be4fa7fe2bee6a2d4d434ffdfd5%2Fexperiment-run-states.png?alt=media) 1. Within step **(1)**, one target execution fails because the HTTP success rate wasn't achieved (target execution's state `FAILED`). 2. Other target executions of the step **(1)** are canceled by the system (target execution's state `CANCELED`). 3. Due to the failed target execution, step **(1)** is also ending as `FAILED`. 4. Steps running in parallel **(2)** are canceled (step's state `CANCELED`, thus all its target execution states are `CANCELED`). 5. Subsequent steps **(3)** are not performed anymore and are indicated as `SKIPPED`. 6. Steps already performed **(4)** beforehand don't change their state (i.e., `COMPLETED`). 7. The experiment will stop immediately in the state `FAILED` **(5)**. #### Example: Continue on Any Failures / Errors In some cases, state propagation is not desirable. Especially when running an experiment that attacks a large number of targets, single targets becoming unavailable may be expected and shouldn't cause the experiment to stop immediately. For these cases, you can configure a step to [continue on any failures or errors](/use-steadybit/experiments/design.md#continue-on-any-failures-or-errors) in the experiment design. Once activated, the above example looks different: ![Experiment run showing state propagation with 'continue on any failures/errors'](https://853194531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZLJS2c8EXBcu8PiwteIJ%2Fuploads%2Fgit-blob-90a50706c43933dd3043ea6c8fd98431f3e88ec9%2Fexperiment-run-states-continue.png?alt=media) 1. Within step **(1)**, one target execution fails because the HTTP success rate wasn't achieved (target execution's state `FAILED`). 2. Other target executions of the step **(1)** continue to run (target execution's state `COMPLETED`). 3. Due to the failed target execution, step **(1)** is still indicated as `FAILED`. 4. Steps running in parallel **(2)** continue to run (step's and target execution's state `COMPLETED`). 5. Subsequent steps **(3)** are performed as usual; if no additional failure or error occurs, the steps' and target executions' states are `COMPLETED`. 6. Steps already performed **(4)** beforehand don't change their state (i.e., `COMPLETED`). 7. The experiment run ended in the state `COMPLETED` **(5)** because the failure of step **(1)** was ignored and all other steps `COMPLETED`.