2014-08-22 00:25:42 +00:00
---
2020-04-07 18:55:19 +00:00
layout: docs
2022-09-23 21:31:00 +00:00
page_title: Watches Overview and Reference
2020-04-07 18:55:19 +00:00
description: >-
2022-10-11 14:35:24 +00:00
Watches monitor the key/value (KV) store, services, nodes, health checks, and events for updates. When a watch detects a change, it invokes a handler that can call an HTTP endpoint or run an executable. Learn how to configure watches to dynamically respond to changes in Consul.
2014-08-22 00:25:42 +00:00
---
2022-09-23 21:31:00 +00:00
# Watches Overview and Reference
2014-08-22 00:25:42 +00:00
2015-02-05 03:25:29 +00:00
Watches are a way of specifying a view of data (e.g. list of nodes, KV pairs, health
checks) which is monitored for updates. When an update is detected, an external handler
2017-10-22 01:39:09 +00:00
is invoked. A handler can be any executable or HTTP endpoint. As an example, you could watch the status
2015-02-05 03:25:29 +00:00
of health checks and notify an external system when a check is critical.
2014-08-22 00:25:42 +00:00
2023-01-25 16:52:43 +00:00
Watches are implemented using blocking queries in the [HTTP API](/consul/api-docs).
2015-02-05 03:25:29 +00:00
Agents automatically make the proper API calls to watch for changes
2014-08-22 00:25:42 +00:00
and inform a handler when the data view has updated.
2023-01-25 16:52:43 +00:00
Watches can be configured as part of the [agent's configuration](/consul/docs/agent/config/config-files#watches),
2014-08-22 00:25:42 +00:00
causing them to run once the agent is initialized. Reloading the agent configuration
allows for adding or removing watches dynamically.
2023-01-25 16:52:43 +00:00
Alternatively, the [watch command](/consul/commands/watch) enables a watch to be
2015-02-05 03:25:29 +00:00
started outside of the agent. This can be used by an operator to inspect data in Consul
2014-08-22 00:25:42 +00:00
or to easily pipe data into processes without being tied to the agent lifecycle.
In either case, the `type` of the watch must be specified. Each type of watch
2015-02-05 03:25:29 +00:00
supports different parameters, some required and some optional. These options are specified
in a JSON body when using agent configuration or as CLI flags for the watch command.
2014-08-22 00:25:42 +00:00
## Handlers
2015-02-05 03:25:29 +00:00
The watch configuration specifies the view of data to be monitored.
2017-10-22 01:51:37 +00:00
Once that view is updated, the specified handler is invoked. Handlers can be either an
2017-10-22 01:55:15 +00:00
executable or an HTTP endpoint. A handler receives JSON formatted data
2017-10-22 01:39:09 +00:00
with invocation info, following a format that depends on the type of the watch.
Each watch type documents the format type. Because they map directly to an HTTP
API, handlers should expect the input to match the format of the API. A Consul
index is also given, corresponding to the responses from the
2023-01-25 16:52:43 +00:00
[HTTP API](/consul/api-docs).
2017-10-22 01:39:09 +00:00
### Executable
An executable handler reads the JSON invocation info from stdin. Additionally,
2022-01-14 00:55:11 +00:00
the `CONSUL_INDEX` environment variable will be set to the Consul index.
2017-10-22 01:39:09 +00:00
Anything written to stdout is logged.
Here is an example configuration, where `handler_type` is optionally set to
`script`:
2022-01-14 00:55:11 +00:00
<CodeTabs heading="Consul watch with script handler defined in agent configuration">
<CodeBlockConfig filename="agent-config.hcl">
```hcl
watches = [
{
type = "key"
key = "foo/bar/baz"
handler_type = "script"
args = ["/usr/bin/my-service-handler.sh", "-redis"]
}
]
```
</CodeBlockConfig>
<CodeBlockConfig filename="agent-config.json">
2020-04-09 00:09:01 +00:00
```json
2017-10-22 01:39:09 +00:00
{
2022-01-14 00:55:11 +00:00
"watches": [
{
"type": "key",
"key": "foo/bar/baz",
"handler_type": "script",
"args": ["/usr/bin/my-service-handler.sh", "-redis"]
}
]
2017-10-22 01:39:09 +00:00
}
```
2014-08-22 00:25:42 +00:00
2022-01-14 00:55:11 +00:00
</CodeBlockConfig>
</CodeTabs>
2017-10-04 23:48:00 +00:00
Prior to Consul 1.0, watches used a single `handler` field to define the command to run, and
would always run in a shell. In Consul 1.0, the `args` array was added so that handlers can be
run without a shell. The `handler` field is deprecated, and you should include the shell in
the `args` to run under a shell, eg. `"args": ["sh", "-c", "..."]`.
2017-10-22 01:39:09 +00:00
### HTTP endpoint
2017-10-22 03:09:37 +00:00
An HTTP handler sends an HTTP request when a watch is invoked. The JSON invocation info is sent
as a payload along the request. The response also contains the Consul index as a header named
`X-Consul-Index`.
2017-10-22 01:51:37 +00:00
The HTTP handler can be configured by setting `handler_type` to `http`. Additional handler options
2017-10-22 03:09:37 +00:00
are set using `http_handler_config`. The only required parameter is the `path` field which specifies
the URL to the HTTP endpoint. Consul uses `POST` as the default HTTP method, but this is also configurable.
2018-09-22 01:30:16 +00:00
Other optional fields are `header`, `timeout` and `tls_skip_verify`. The watch invocation data is
2017-10-22 03:09:37 +00:00
always sent as a JSON payload.
2017-10-22 01:39:09 +00:00
Here is an example configuration:
2022-01-14 00:55:11 +00:00
<CodeTabs heading="Consul watch with HTTP handler defined in agent configuration">
<CodeBlockConfig filename="agent-config.hcl">
```hcl
watches = [
{
type = "key"
key = "foo/bar/baz"
handler_type = "http"
http_handler_config {
path = "https://localhost:8000/watch"
method = "POST"
header = {
x-foo = ["bar", "baz"]
}
timeout = "10s"
tls_skip_verify = false
}
}
]
```
</CodeBlockConfig>
<CodeBlockConfig filename="agent-config.json">
2020-04-09 00:09:01 +00:00
```json
2017-10-22 01:39:09 +00:00
{
2022-01-14 00:55:11 +00:00
"watches": [
{
"type": "key",
"key": "foo/bar/baz",
"handler_type": "http",
"http_handler_config": {
"path": "https://localhost:8000/watch",
"method": "POST",
"header": { "x-foo": ["bar", "baz"] },
"timeout": "10s",
"tls_skip_verify": false
}
}
]
2017-10-22 01:39:09 +00:00
}
```
2022-01-14 00:55:11 +00:00
</CodeBlockConfig>
</CodeTabs>
2014-08-22 00:25:42 +00:00
## Global Parameters
In addition to the parameters supported by each option type, there
are a few global parameters that all watches support:
2020-04-06 20:27:35 +00:00
- `datacenter` - Can be provided to override the agent's default datacenter.
- `token` - Can be provided to override the agent's default ACL token.
- `args` - The handler subprocess and arguments to invoke when the data view updates.
- `handler` - The handler shell command to invoke when the data view updates.
2014-08-22 00:25:42 +00:00
## Watch Types
2015-02-05 03:28:10 +00:00
The following types are supported. Detailed documentation on each is below:
2014-08-22 00:25:42 +00:00
2020-04-06 20:27:35 +00:00
- [`key`](#key) - Watch a specific KV pair
- [`keyprefix`](#keyprefix) - Watch a prefix in the KV store
- [`services`](#services) - Watch the list of available services
- [`nodes`](#nodes) - Watch the list of nodes
- [`service`](#service)- Watch the instances of a service
- [`checks`](#checks) - Watch the value of health checks
- [`event`](#event) - Watch for custom user events
2014-08-22 00:25:42 +00:00
2020-04-09 00:09:01 +00:00
### Type: key ((#key))
2014-08-22 00:25:42 +00:00
The "key" watch type is used to watch a specific key in the KV store.
2022-01-14 00:55:11 +00:00
It requires that the `key` parameter be specified.
2014-08-22 00:25:42 +00:00
This maps to the `/v1/kv/` API internally.
Here is an example configuration:
2022-01-14 00:55:11 +00:00
<CodeTabs heading="Example key watch type">
```hcl
{
type = "key"
key = "foo/bar/baz"
args = ["/usr/bin/my-service-handler.sh", "-redis"]
}
```
2021-07-31 01:37:33 +00:00
```json
2014-10-19 23:40:10 +00:00
{
"type": "key",
"key": "foo/bar/baz",
2017-10-04 23:48:00 +00:00
"args": ["/usr/bin/my-service-handler.sh", "-redis"]
2014-10-19 23:40:10 +00:00
}
```
2014-08-22 00:25:42 +00:00
2022-01-14 00:55:11 +00:00
</CodeTabs>
2014-08-22 00:25:42 +00:00
Or, using the watch command:
2020-05-19 18:32:38 +00:00
```shell-session
2020-04-09 00:09:01 +00:00
$ consul watch -type=key -key=foo/bar/baz /usr/bin/my-key-handler.sh
```
2014-08-22 00:25:42 +00:00
An example of the output of this command:
2020-04-09 00:09:01 +00:00
```json
2014-10-19 23:40:10 +00:00
{
"Key": "foo/bar/baz",
"CreateIndex": 1793,
"ModifyIndex": 1793,
"LockIndex": 0,
"Flags": 0,
"Value": "aGV5",
"Session": ""
}
```
2014-08-22 00:25:42 +00:00
2020-04-09 00:09:01 +00:00
### Type: keyprefix ((#keyprefix))
2014-08-22 00:25:42 +00:00
2022-01-14 00:55:11 +00:00
The `keyprefix` watch type is used to watch a prefix of keys in the KV store.
It requires that the `prefix` parameter be specified. This watch
2020-04-06 20:27:35 +00:00
returns _all_ keys matching the prefix whenever _any_ key matching the prefix
2015-06-12 14:07:42 +00:00
changes.
2014-08-22 00:25:42 +00:00
This maps to the `/v1/kv/` API internally.
Here is an example configuration:
2022-01-14 00:55:11 +00:00
<CodeTabs heading="Example keyprefix watch type">
```hcl
{
type = "keyprefix"
prefix = "foo/"
args = ["/usr/bin/my-prefix-handler.sh", "-redis"]
}
```
2020-04-09 00:09:01 +00:00
```json
2014-10-19 23:40:10 +00:00
{
"type": "keyprefix",
"prefix": "foo/",
2019-11-06 04:34:46 +00:00
"args": ["/usr/bin/my-prefix-handler.sh", "-redis"]
2014-10-19 23:40:10 +00:00
}
```
2014-08-22 00:25:42 +00:00
2022-01-14 00:55:11 +00:00
</CodeTabs>
2014-08-22 00:25:42 +00:00
Or, using the watch command:
2020-05-19 18:32:38 +00:00
```shell-session
2020-04-09 00:09:01 +00:00
$ consul watch -type=keyprefix -prefix=foo/ /usr/bin/my-prefix-handler.sh
```
2014-08-22 00:25:42 +00:00
An example of the output of this command:
2022-01-14 00:55:11 +00:00
```json
2020-04-09 00:09:01 +00:00
[
2014-10-19 23:40:10 +00:00
{
2022-01-14 00:55:11 +00:00
"Key": "foo/bar",
"CreateIndex": 1796,
"ModifyIndex": 1796,
"LockIndex": 0,
"Flags": 0,
"Value": "TU9BUg==",
"Session": ""
2014-10-19 23:40:10 +00:00
},
{
2022-01-14 00:55:11 +00:00
"Key": "foo/baz",
"CreateIndex": 1795,
"ModifyIndex": 1795,
"LockIndex": 0,
"Flags": 0,
"Value": "YXNkZg==",
"Session": ""
2014-10-19 23:40:10 +00:00
},
{
2022-01-14 00:55:11 +00:00
"Key": "foo/test",
"CreateIndex": 1793,
"ModifyIndex": 1793,
"LockIndex": 0,
"Flags": 0,
"Value": "aGV5",
"Session": ""
}
2014-10-19 23:40:10 +00:00
]
```
2014-08-22 00:25:42 +00:00
2020-04-09 00:09:01 +00:00
### Type: services ((#services))
2014-08-22 00:25:42 +00:00
The "services" watch type is used to watch the list of available
services. It has no parameters.
This maps to the `/v1/catalog/services` API internally.
2022-01-14 00:55:11 +00:00
Below is an example configuration:
<CodeTabs heading="Example services watch type">
```hcl
{
type = "services"
args = ["/usr/bin/my-services-handler.sh"]
}
```
```json
{
"type": "services",
"args": ["/usr/bin/my-services-handler.sh"]
}
```
</CodeTabs>
Or, using the watch command:
```shell-session
$ consul watch -type=services /usr/bin/my-services-handler.sh
```
2014-08-22 00:25:42 +00:00
An example of the output of this command:
2020-04-09 00:09:01 +00:00
```json
2014-10-19 23:40:10 +00:00
{
"consul": [],
"redis": [],
"web": []
}
```
2014-08-22 00:25:42 +00:00
2020-04-09 00:09:01 +00:00
### Type: nodes ((#nodes))
2014-08-22 00:25:42 +00:00
The "nodes" watch type is used to watch the list of available
nodes. It has no parameters.
This maps to the `/v1/catalog/nodes` API internally.
2022-01-14 00:55:11 +00:00
Below is an example configuration:
<CodeTabs heading="Example nodes watch type">
```hcl
{
type = "nodes"
args = ["/usr/bin/my-nodes-handler.sh"]
}
```
```json
{
"type": "nodes",
"args": ["/usr/bin/my-nodes-handler.sh"]
}
```
</CodeTabs>
Or, using the watch command:
```shell-session
$ consul watch -type=nodes /usr/bin/my-nodes-handler.sh
```
2014-08-22 00:25:42 +00:00
An example of the output of this command:
2022-01-14 00:55:11 +00:00
```json
2020-04-09 00:09:01 +00:00
[
2014-10-19 23:40:10 +00:00
{
2022-01-14 00:55:11 +00:00
"ID": "8d3088b5-ce7d-0b94-f185-ae70c3445642",
"Node": "nyc1-consul-1",
"Address": "192.0.2.10",
"Datacenter": "dc1",
"TaggedAddresses": null,
"Meta": null,
"CreateIndex": 23792324,
"ModifyIndex": 23792324
2014-10-19 23:40:10 +00:00
},
{
2022-01-14 00:55:11 +00:00
"ID": "1edb564e-65ee-9e60-5e8a-83eae4637357",
"Node": "nyc1-worker-1",
"Address": "192.0.2.20",
"Datacenter": "dc1",
"TaggedAddresses": {
"lan": "192.0.2.20",
"lan_ipv4": "192.0.2.20",
"wan": "192.0.2.20",
"wan_ipv4": "192.0.2.20"
},
"Meta": {
"consul-network-segment": "",
"host-ip": "192.0.2.20",
"pod-name": "hashicorp-consul-q7nth"
},
"CreateIndex": 23792336,
"ModifyIndex": 23792338
2020-04-09 00:09:01 +00:00
}
2014-10-19 23:40:10 +00:00
]
```
2014-08-22 00:25:42 +00:00
2020-04-09 00:09:01 +00:00
### Type: service ((#service))
2014-08-22 00:25:42 +00:00
The "service" watch type is used to monitor the providers
2022-01-14 00:55:11 +00:00
of a single service. It requires the `service` parameter
and optionally takes the parameters `tag` and
`passingonly`. The `tag` parameter will filter by one or more tags.
2019-04-29 19:28:01 +00:00
It may be either a single string value or a slice of strings.
2022-01-14 00:55:11 +00:00
The `passingonly` parameter is a boolean that will filter to only the
2019-04-29 19:28:01 +00:00
instances passing all health checks.
2014-08-22 00:25:42 +00:00
This maps to the `/v1/health/service` API internally.
2019-04-29 19:28:01 +00:00
Here is an example configuration with a single tag:
2014-08-22 00:25:42 +00:00
2022-01-14 00:55:11 +00:00
<CodeTabs heading="Example service watch type">
```hcl
{
type = "service"
service = "redis"
args = ["/usr/bin/my-service-handler.sh", "-redis"]
tag = "bar"
}
```
2020-04-09 00:09:01 +00:00
```json
2014-10-19 23:40:10 +00:00
{
"type": "service",
2014-12-27 05:51:48 +00:00
"service": "redis",
2019-04-29 19:28:01 +00:00
"args": ["/usr/bin/my-service-handler.sh", "-redis"],
"tag": "bar"
}
```
2022-01-14 00:55:11 +00:00
</CodeTabs>
2019-04-29 19:28:01 +00:00
Here is an example configuration with multiple tags:
2022-01-14 00:55:11 +00:00
<CodeTabs heading="Example service watch type with multiple tags">
```hcl
{
type = "service"
service = "redis"
args = ["/usr/bin/my-service-handler.sh", "-redis"]
tag = ["bar", "foo"]
}
```
2020-04-09 00:09:01 +00:00
```json
2019-04-29 19:28:01 +00:00
{
"type": "service",
"service": "redis",
"args": ["/usr/bin/my-service-handler.sh", "-redis"],
"tag": ["bar", "foo"]
2014-10-19 23:40:10 +00:00
}
```
2014-08-22 00:25:42 +00:00
2022-01-14 00:55:11 +00:00
</CodeTabs>
2014-08-22 00:25:42 +00:00
Or, using the watch command:
2019-04-29 19:28:01 +00:00
Single tag:
2020-05-19 18:32:38 +00:00
```shell-session
2020-04-09 00:09:01 +00:00
$ consul watch -type=service -service=redis -tag=bar /usr/bin/my-service-handler.sh
```
2019-04-29 19:28:01 +00:00
2022-01-14 00:55:11 +00:00
Multiple tags:
2019-04-29 19:28:01 +00:00
2020-05-19 18:32:38 +00:00
```shell-session
2020-04-09 00:09:01 +00:00
$ consul watch -type=service -service=redis -tag=bar -tag=foo /usr/bin/my-service-handler.sh
```
2014-08-22 00:25:42 +00:00
An example of the output of this command:
2022-01-14 00:55:11 +00:00
```json
2020-04-09 00:09:01 +00:00
[
2014-10-19 23:40:10 +00:00
{
2022-01-14 00:55:11 +00:00
"Node": {
"ID": "f013522f-aaa2-8fc6-c8ac-c84cb8a56405",
"Node": "hashicorp-consul-server-1",
"Address": "192.0.2.50",
"Datacenter": "dc1",
"TaggedAddresses": null,
"Meta": null,
"CreateIndex": 23785783,
"ModifyIndex": 23785783
2014-10-19 23:40:10 +00:00
},
2022-01-14 00:55:11 +00:00
"Service": {
"ID": "redis",
"Service": "redis",
"Tags": [],
"Meta": null,
"Port": 6379,
"Address": "",
"Weights": {
"Passing": 1,
"Warning": 1
2014-10-19 23:40:10 +00:00
},
2022-01-14 00:55:11 +00:00
"EnableTagOverride": false,
"CreateIndex": 23785794,
"ModifyIndex": 23785794,
"Proxy": {
"MeshGateway": {},
"Expose": {}
2020-04-06 20:27:35 +00:00
},
2022-01-14 00:55:11 +00:00
"Connect": {}
},
"Checks": [
{
"Node": "hashicorp-consul-server-1",
"CheckID": "serfHealth",
"Name": "Serf Health Status",
"Status": "passing",
"Notes": "",
"Output": "Agent alive and reachable",
"ServiceID": "",
"ServiceName": "",
"ServiceTags": [],
"Type": "",
"Definition": {
"Interval": "0s",
"Timeout": "0s",
"DeregisterCriticalServiceAfter": "0s",
"HTTP": "",
"Header": null,
"Method": "",
"Body": "",
"TLSServerName": "",
"TLSSkipVerify": false,
"TCP": "",
2023-09-05 20:34:44 +00:00
"TCPUseTLS": false,
2022-01-14 00:55:11 +00:00
"GRPC": "",
"GRPCUseTLS": false
},
"CreateIndex": 23785783,
"ModifyIndex": 23791503
}
]
2020-04-09 00:09:01 +00:00
}
2014-10-19 23:40:10 +00:00
]
```
2014-08-22 00:25:42 +00:00
2020-04-09 00:09:01 +00:00
### Type: checks ((#checks))
2014-08-22 00:25:42 +00:00
The "checks" watch type is used to monitor the checks of a given
2022-01-14 00:55:11 +00:00
service or those in a specific state. It optionally takes the `service`
parameter to filter to a specific service or the `state` parameter to
2015-02-05 03:25:29 +00:00
filter to a specific state. By default, it will watch all checks.
2014-08-22 00:25:42 +00:00
2015-02-05 03:25:29 +00:00
This maps to the `/v1/health/state/` API if monitoring by state
2014-08-22 00:25:42 +00:00
or `/v1/health/checks/` if monitoring by service.
2019-11-02 06:18:46 +00:00
Here is an example configuration for monitoring by state:
2022-01-14 00:55:11 +00:00
<CodeTabs heading="Example checks watch type for all services in the passing state">
```hcl
{
type = "checks"
state = "passing"
args = ["/usr/bin/my-check-handler.sh", "-passing"]
}
```
2019-11-02 06:18:46 +00:00
```json
{
"type": "checks",
"state": "passing",
"args": ["/usr/bin/my-check-handler.sh", "-passing"]
}
```
2022-01-14 00:55:11 +00:00
</CodeTabs>
2019-11-02 06:18:46 +00:00
Here is an example configuration for monitoring by service:
2022-01-14 00:55:11 +00:00
<CodeTabs heading="Example checks watch type for a specific service">
```hcl
{
type = "checks"
service = "redis"
args = ["/usr/bin/my-check-handler.sh", "-redis"]
}
```
2019-11-02 06:18:46 +00:00
```json
{
"type": "checks",
"service": "redis",
"args": ["/usr/bin/my-check-handler.sh", "-redis"]
}
```
2022-01-14 00:55:11 +00:00
</CodeTabs>
2019-11-02 06:18:46 +00:00
Or, using the watch command:
State:
2020-05-19 18:32:38 +00:00
```shell-session
2020-04-09 00:09:01 +00:00
$ consul watch -type=checks -state=passing /usr/bin/my-check-handler.sh -passing
```
2019-11-02 06:18:46 +00:00
Service:
2020-05-19 18:32:38 +00:00
```shell-session
2020-04-09 00:09:01 +00:00
$ consul watch -type=checks -service=redis /usr/bin/my-check-handler.sh -redis
```
2019-11-02 06:18:46 +00:00
2014-08-22 00:25:42 +00:00
An example of the output of this command:
2019-11-02 06:18:46 +00:00
```json
2014-10-19 23:40:10 +00:00
[
{
"Node": "foobar",
"CheckID": "service:redis",
"Name": "Service 'redis' check",
"Status": "passing",
"Notes": "",
"Output": "",
"ServiceID": "redis",
"ServiceName": "redis"
}
]
```
2014-08-29 00:22:56 +00:00
2020-04-09 00:09:01 +00:00
### Type: event ((#event))
2014-08-29 00:22:56 +00:00
The "event" watch type is used to monitor for custom user
2023-01-25 16:52:43 +00:00
events. These are fired using the [consul event](/consul/commands/event) command.
2022-01-14 00:55:11 +00:00
It takes only a single optional `name` parameter which restricts
2014-08-29 00:22:56 +00:00
the watch to only events with the given name.
2019-11-06 04:34:46 +00:00
This maps to the `/v1/event/list` API internally.
2014-08-29 00:22:56 +00:00
Here is an example configuration:
2022-01-14 00:55:11 +00:00
<CodeTabs heading="Example event watch type">
```hcl
{
type = "event"
name = "web-deploy"
args = ["/usr/bin/my-event-handler.sh", "-web-deploy"]
}
```
2020-04-09 00:09:01 +00:00
```json
2014-10-19 23:40:10 +00:00
{
"type": "event",
"name": "web-deploy",
2019-11-06 04:34:46 +00:00
"args": ["/usr/bin/my-event-handler.sh", "-web-deploy"]
2014-10-19 23:40:10 +00:00
}
```
2014-08-29 00:22:56 +00:00
2022-01-14 00:55:11 +00:00
</CodeTabs>
2014-08-29 00:22:56 +00:00
Or, using the watch command:
2020-05-19 18:32:38 +00:00
```shell-session
2020-04-09 00:09:01 +00:00
$ consul watch -type=event -name=web-deploy /usr/bin/my-event-handler.sh -web-deploy
```
2014-08-29 00:22:56 +00:00
An example of the output of this command:
2020-04-09 00:09:01 +00:00
```json
2014-10-19 23:40:10 +00:00
[
{
"ID": "f07f3fcc-4b7d-3a7c-6d1e-cf414039fcee",
"Name": "web-deploy",
"Payload": "MTYwOTAzMA==",
"NodeFilter": "",
"ServiceFilter": "",
"TagFilter": "",
"Version": 1,
"LTime": 18
2023-09-21 18:35:16 +00:00
}
2014-10-19 23:40:10 +00:00
]
```
2014-08-29 00:22:56 +00:00
To fire a new `web-deploy` event the following could be used:
2020-05-19 18:32:38 +00:00
```shell-session
2020-04-09 00:09:01 +00:00
$ consul event -name=web-deploy 1609030
```