# Run a watch


**POST /_watcher/watch/{id}/_execute**

**All methods and paths for this operation:**

<div>
                      <span class="operation-verb put">PUT</span>
                      <span class="operation-path">/_watcher/watch/_execute</span>
                      </div>
                    <div>
                      <span class="operation-verb post">POST</span>
                      <span class="operation-path">/_watcher/watch/_execute</span>
                      </div>
                    <div>
                      <span class="operation-verb put">PUT</span>
                      <span class="operation-path">/_watcher/watch/{id}/_execute</span>
                      </div>
                    <div>
                      <span class="operation-verb post">POST</span>
                      <span class="operation-path">/_watcher/watch/{id}/_execute</span>
                      </div>
                    

This API can be used to force execution of the watch outside of its triggering logic or to simulate the watch execution for debugging purposes.

For testing and debugging purposes, you also have fine-grained control on how the watch runs.
You can run the watch without running all of its actions or alternatively by simulating them.
You can also force execution by ignoring the watch condition and control whether a watch record would be written to the watch history after it runs.

You can use the run watch API to run watches that are not yet registered by specifying the watch definition inline.
This serves as great tool for testing and debugging your watches prior to adding them to Watcher.

When Elasticsearch security features are enabled on your cluster, watches are run with the privileges of the user that stored the watches.
If your user is allowed to read index `a`, but not index `b`, then the exact same set of rules will apply during execution of a watch.

When using the run watch API, the authorization data of the user that called the API will be used as a base, instead of the information who stored the watch.
Refer to the external documentation for examples of watch execution requests, including existing, customized, and inline watches.

## Required authorization

* Cluster privileges: `manage_watcher`


[More about executing a watch](https://www.elastic.co/docs/explore-analyze/alerts-cases/watcher/execute-watch)

## Servers
- http://api.example.com: http://api.example.com ()


## Authentication methods
- Api key auth
- Basic auth
- Bearer auth


## Parameters

### Path parameters
- **id** (string)
  The watch identifier.

### Query parameters
- **debug** (boolean)
  Defines whether the watch runs in debug mode.

### Body: application/json (object)

- **action_modes** (object)
  Determines how to handle the watch actions as part of the watch execution.
- **alternative_input** (object)
  When present, the watch uses this object as a payload instead of executing its own input.
- **ignore_condition** (boolean)
  When set to `true`, the watch execution uses the always condition. This can also be specified as an HTTP parameter.
- **record_execution** (boolean)
  When set to `true`, the watch record representing the watch execution result is persisted to the `.watcher-history` index for the current time.
  In addition, the status of the watch is updated, possibly throttling subsequent runs.
  This can also be specified as an HTTP parameter.
- **simulated_actions** (object)

- **trigger_data** (object)
  This structure is parsed as the data of the trigger event that will be used during the watch execution.
- **watch** (object)
  When present, this watch is used instead of the one specified in the request.
  This watch is not persisted to the index and `record_execution` cannot be set.


## Responses
### 200


#### Body: application/json (object)
- **_id** (string)
  The watch record identifier as it would be stored in the `.watcher-history` index.
- **watch_record** (object)
  The watch record document as it would be stored in the `.watcher-history` index.


[Powered by Bump.sh](https://bump.sh)