a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
89 lines
2.7 KiB
Markdown
89 lines
2.7 KiB
Markdown
---
|
||
layout: "api"
|
||
page_title: "/sys/health - HTTP API"
|
||
sidebar_title: "<tt>/sys/health</tt>"
|
||
sidebar_current: "api-http-system-health"
|
||
description: |-
|
||
The `/sys/health` endpoint is used to check the health status of Vault.
|
||
---
|
||
|
||
# `/sys/health`
|
||
|
||
The `/sys/health` endpoint is used to check the health status of Vault.
|
||
|
||
## Read Health Information
|
||
|
||
This endpoint returns the health status of Vault. This matches the semantics of
|
||
a Consul HTTP health check and provides a simple way to monitor the health of a
|
||
Vault instance.
|
||
|
||
| Method | Path | Produces |
|
||
| :------- | :--------------------------- | :--------------------- |
|
||
| `HEAD` | `/sys/health` | `000 (empty body)` |
|
||
| `GET` | `/sys/health` | `000 application/json` |
|
||
|
||
The default status codes are:
|
||
|
||
- `200` if initialized, unsealed, and active
|
||
- `429` if unsealed and standby
|
||
- `472` if data recovery mode replication secondary and active
|
||
- `473` if performance standby
|
||
- `501` if not initialized
|
||
- `503` if sealed
|
||
|
||
### Parameters
|
||
|
||
- `standbyok` `(bool: false)` – Specifies if being a standby should still return
|
||
the active status code instead of the standby status code. This is useful when
|
||
Vault is behind a non-configurable load balance that just wants a 200-level
|
||
response.
|
||
|
||
- `activecode` `(int: 200)` – Specifies the status code that should be returned
|
||
for an active node.
|
||
|
||
- `standbycode` `(int: 429)` – Specifies the status code that should be returned
|
||
for a standby node.
|
||
|
||
- `drsecondarycode` `(int: 472)` – Specifies the status code that should be
|
||
returned for a DR secondary node.
|
||
|
||
- `performancestandbycode` `(int: 473)` – Specifies the status code that should be
|
||
returned for a performance standby node.
|
||
|
||
- `sealedcode` `(int: 503)` – Specifies the status code that should be returned
|
||
for a sealed node.
|
||
|
||
- `uninitcode` `(int: 501)` – Specifies the status code that should be returned
|
||
for a uninitialized node.
|
||
|
||
### Sample Request
|
||
|
||
```
|
||
$ curl \
|
||
http://127.0.0.1:8200/v1/sys/health
|
||
```
|
||
|
||
### Sample Response
|
||
|
||
This response is only returned for a `GET` request.
|
||
|
||
Note: `replication_perf_mode` and `replication_dr_mode` reflect the state of
|
||
the active node in the cluster; if you are querying it for a standby that has
|
||
just come up, it can take a small time for the active node to inform the
|
||
standby of its status.
|
||
|
||
```json
|
||
{
|
||
"initialized": true,
|
||
"sealed": false,
|
||
"standby": false,
|
||
"performance_standby": false,
|
||
"replication_perf_mode": "disabled",
|
||
"replication_dr_mode": "disabled",
|
||
"server_time_utc": 1516639589,
|
||
"version": "0.9.1",
|
||
"cluster_name": "vault-cluster-3bd69ca2",
|
||
"cluster_id": "00af5aa8-c87d-b5fc-e82e-97cd8dfaf731"
|
||
}
|
||
```
|