Skip to content
Headless Platform
GitHubDiscordYouTube

HTTP health checks for headless WordPress environments

HTTP Health Check Explained

HTTP health check on the Headless Platform is a check that runs at a high frequency at the environment startup - and then periodically while the environment is running to ensure it is operating correctly.

Once set up, during every deployment the platform will wait for the health check to respond with a successful response (HTTP code >=200 and <400) before marking the deployment as successful. Then, if the environment starts failing while it’s already running (health check will start returning HTTP code >=400), the platform will restart the environment.

A health check must be configured by the developer to be enabled for each of the environments that they wished to be monitored.

Behavior during the environment startup

By default (without the HTTP health check enabled) Headless Platform checks if your environment has bound to a port (see more details in our documentation). Once it has done so successfully, the environment will be marked as healthy and the deployment as successful which means that your environment is ready to serve the traffic.

If the health check is enabled on your environment, it will instead wait for the environment to respond with an 200 response before marking it as healthy.

Behavior during the environment runtime

By default (without the HTTP health check enabled), if the environment is bound to a port our platform will not treat it as unhealthy if it starts returning HTTP 5xx responses.

However once the health check is configured, the environment will be restarted if it starts returning HTTP 5xx responses.

Steps to Enable the HTTP Health Check

Add a Health Check Endpoint

Add an endpoint to your environment which returns an HTTP 200 response. For example, add the following under the /api/healthz.js file

export default function handler(req, res) {
  res.status(200).json({ status: "ok" });
}

Notes:

  1. At startup, the endpoint will get a large volume of requests until it starts returning an HTTP 200 response. This means you should not include load sensitive components as part of this health check, such as the WordPress backend.
  2. Additionally, this health check should only test the headless frontend. If it includes the back end in this health check and the WordPress goes unhealthy, the frontend could be restarted unnecessarily, causing more problems with your website.
  3. The path of the file itself does not matter and can be set to any value.

Enable Using Environment Variables

The following environment variables must be added to the headless environment via the User Portal. The path must be the same as the path of the endpoint set up above.

HTTP_HEALTH_CHECK_ENABLED=true
HTTP_HEALTH_CHECK_PATH=/api/healthz

Note: Modifying environment variables does not trigger a new deployment automatically - a new deployment (either through a manual rebuild or a new commit to the source branch) is needed for the health check to be applied.

See it Working

Once the environment is deployed successfully, the new health check will be working.

Notes:

  1. Logs of the health check do not show up in the headless access logs.
  2. If you wish to do so, you can add logging to the health check endpoint, but due to the high volume of requests and regular checking it is not advised to do this.