Title: Health checks
Author: WordPress VIP Documentation
Published: April 6, 2022
Last modified: January 1, 2026

---

 1. [Node.js on VIP](https://docs.wpvip.com/node-js/)
 2. Health checks

#  Health checks

The cache health check endpoint is used to determine whether an application container
is healthy, and allows the VIP edge load balancers to identify application containers
that are extremely busy or non-responsive. If the health check request is not handled
quickly, or if it returns a HTTP status code other than `200`, the application container
will be marked “unhealthy”. Unhealthy containers will not receive traffic for a 
short time until they have recovered.

 * Applications with inconsistent or poor health checks can be unstable, can experience
   downtime, and can fail to deploy.
 * The VIP Platform sends frequent health checks to all Node.js applications at 
   the `/cache-healthcheck?` endpoint.
 * The structure of this endpoint cannot be customized, and must include an empty
   query string (`?`) and lack a trailing slash.
 * Because Node.js server implementations vary widely, VIP cannot implement this
   health check endpoint automatically. Therefore, as a requirement for running 
   on the VIP platform, all Node.js applications must implement this endpoint using
   application code.
 * Examples in the [Node.js skeleton](https://github.com/Automattic/vip-go-node-skeleton/tree/trunk/examples)
   and [Next.js boilerplate](https://github.com/Automattic/vip-go-nextjs-skeleton/blob/trunk/middleware.ts)
   repositories show methods for implementing the health check endpoint in several
   popular Node.js frameworks.

## Strategies for successful health checks

 * **First and final.** Take a “first and final” approach when implementing the 
   health check endpoint: It should be the **first** thing an application does when
   responding to a request, and the result should be **final**—that is, it should
   return a response immediately without giving other code an opportunity to modify
   it.
 * **Postpone heavy operations.** Delay any intensive or asynchronous operations(
   like fetching data) until after the health check has been handled. Applications
   should provide a consistently quick response that is not dependent on any external
   systems.
 * **Postpone redirects.** The health check should be handled before any redirects
   are implemented by an application. This prevents accidental matches that could
   cause the health check endpoint to respond with `3xx` instead of `200`. Be especially
   aware of any “trailing-slash redirects” implemented by an application or its 
   underlying framework.
 * **Ignore the hostname.** Only consider the path (`/cache-healthcheck?`) when 
   identifying health check requests. Health checks are sent internally within VIP’s
   platform, so they do not use custom / mapped domains.
 * **Keep it short.** Health checks are frequent and the response body is ignored,
   so short responses save time. Consider responding with “`Ok`” to allow quick,
   human validation.

## Simulate a health check on a local machine

For a Node.js application that is running on a local machine, `curl -I` can be run
against the application’s health check endpoint to check the status.

In this example, `curl -I` is run against an application running at `http://localhost:
3000`:

    ```wp-block-preformatted
    $ curl -I "http://localhost:3000/cache-healthcheck?"
    HTTP/1.1 200 OK
    X-Powered-By: Express
    Content-Type: text/plain; charset=utf-8
    Content-Length: 2
    ```

The HTTP status code `200` is returned in the command output, indicating that the
application passes the health check. Any status code other than `200` indicates 
a failed health check.

Last updated: January 01, 2026