Set custom WordPress Readiness Probe

Details on how to tweak the readiness probe timings and path.

You might wish to tweak the readiness probe of the WordPress container, if the containers on which it depends take longer than usual to become ready, or if you want to use a custom health check. This document will explain how it can be done.


Before running these commands make sure you connect to your cluster.

1. Stop the dashboard-controller from overriding your custom changes.

You’ll need your Project Namespace and Site Name for these commands, which you can see in the Bitpoke App, in the Runtime section of your site .

For this example, let’s assume the project namespace is proj-jqojzq and the site name is my-site-com-h9wgm.

The command below will tell the dashboard-controller only to reconcile the host header of the readiness probe. So when the site’s primary domain (the first domain in the domains list) changes, it will reflect in the readiness probe as well:

kubectl annotate wordpress -n proj-jqojzq my-site-com-h9wgm

If you want to be able to change the host as well, you may stop the dashboard-controller from reconciling the readiness probe altogether, by issuing the following command:

kubectl annotate wordpress -n proj-jqojzq my-site-com-h9wgm

2. Make the changes you want to the readiness probe

Run the following command:

kubectl edit wordpress -n proj-jqojzq my-site-com-h9wgm

Edit the readinessProbe section, which can be found under the spec section. There are other readiness probes belonging to other containers, so make sure you edit the right one. It should initially look like this:

    failureThreshold: 3
      - name: Host
      path: /?nocache
      port: 8080
    initialDelaySeconds: 10
    periodSeconds: 5
    successThreshold: 1
    timeoutSeconds: 30

3. If you wish to revert to the default readiness probe [optional]

The following commands will revert your custom changes:

kubectl annotate wordpress -n proj-jqojzq my-site-com-h9wgm