docs: Add docs on worker health check

Relates to #994

docs/content/developer-guide/deployment.md

@@ -36,11 +36,16 @@ For a production Vendure server, there are a few security-related points to cons
 
 ## Health/Readiness Checks
 
-If you wish to deploy with Kubernetes or some similar system, you can make use of the health check endpoint. This is a regular REST route (note: _not_ GraphQL), available at `/health`.
+If you wish to deploy with Kubernetes or some similar system, you can make use of the health check endpoints. 
+
+### Server
+
+This is a regular REST route (note: _not_ GraphQL), available at `/health`.
 
 ```text 
 REQUEST: GET http://localhost:3000/health
 ```
+ 
 ```json
 {
   "status": "ok",
@@ -60,6 +65,33 @@ REQUEST: GET http://localhost:3000/health
 
 Health checks are built on the [Nestjs Terminus module](https://docs.nestjs.com/recipes/terminus). You can also add your own health checks by creating plugins that make use of the [HealthCheckRegistryService]({{< relref "health-check-registry-service" >}}).
 
+### Worker
+
+Although the worker is not designed as an HTTP server, it contains a minimal HTTP server specifically to support HTTP health checks. To enable this, you need to call the `startHealthCheckServer()` method after bootstrapping the worker:
+
+```TypeScript
+bootstrapWorker(config)
+  .then(worker => worker.startJobQueue())
+  .then(worker => worker.startHealthCheckServer({ port: 3020 }))
+  .catch(err => {
+    console.log(err);
+  });
+```
+This will make the `/health` endpoint available. When the worker instance is running, it will return the following:
+
+```text 
+REQUEST: GET http://localhost:3020/health
+```
+
+```json
+{
+  "status": "ok"
+}
+```
+{{< alert >}}
+**Note:** there is also an _internal_ health check mechanism for the worker, which does not uses HTTP. This is used by the server's own health check to verify whether at least one worker is running. It works by adding a `check-worker-health` job to the JobQueue and checking that it got processed.
+{{< /alert >}}
+
 ## Admin UI
 
 If you have customized the Admin UI with extensions, it can make sense to [compile your extensions ahead-of-time as part of the deployment process]({{< relref "/docs/plugins/extending-the-admin-ui" >}}#compiling-as-a-deployment-step).

docs/content/developer-guide/overview/_index.md

@@ -13,7 +13,7 @@ Here is a simplified diagram of the Vendure application architecture:
 
 ## Entry Points
 
-As you can see in the diagram, there are two entry points into the application: [`bootstrap()`]({{< relref "bootstrap" >}}) and [`bootstrapWorker()`]({{< relref "bootstrap-worker" >}}), which start the main server and the [worker]({{< relref "vendure-worker" >}}) respectively. Communication between server and worker(s) is done via the [Job Queue]({{< relref "/docs/developer-guide/job-queue" >}}).
+As you can see in the diagram, there are two entry points into the application: [`bootstrap()`]({{< relref "bootstrap" >}}) and [`bootstrapWorker()`]({{< relref "bootstrap-worker" >}}), which start the main server and the [worker]({{< relref "/docs/developer-guide/vendure-worker" >}}) respectively. Communication between server and worker(s) is done via the [Job Queue]({{< relref "/docs/developer-guide/job-queue" >}}).
 
 ## GraphQL APIs
 

docs/content/plugins/plugin-architecture/_index.md

@@ -10,7 +10,7 @@ showtoc: true
 
 A plugin in Vendure is a specialized Nestjs Module which is decorated with the [`VendurePlugin` class decorator]({{< relref "vendure-plugin" >}}). This diagram illustrates the how a plugin can integrate with and extend Vendure.
  
-1. A Plugin may define logic to be run by the [Vendure Worker]({{< relref "vendure-worker" >}}). This is suitable for long-running or resource-intensive tasks and is done by providing controllers via the [`workers` metadata property]({{< relref "vendure-plugin-metadata" >}}#workers).
+1. A Plugin may define logic to be run by the [Vendure Worker]({{< relref "/docs/developer-guide/vendure-worker" >}}). This is suitable for long-running or resource-intensive tasks and is done by providing controllers via the [`workers` metadata property]({{< relref "vendure-plugin-metadata" >}}#workers).
 2. A Plugin can modify any aspect of server configuration via the [`configuration` metadata property]({{< relref "vendure-plugin-metadata" >}}#configuration).
 3. A Plugin can extend the GraphQL APIs via the [`shopApiExtensions` metadata property]({{< relref "vendure-plugin-metadata" >}}#shopapiextensions) and the [`adminApiExtensions` metadata property]({{< relref "vendure-plugin-metadata" >}}#adminapiextensions).
 4. A Plugin can interact with Vendure by importing the [`PluginCommonModule`]({{< relref "plugin-common-module" >}}), by which it may inject any of the core Vendure services (which are responsible for all interaction with the database as well as business logic). Additionally a plugin may define new database entities via the [`entities` metadata property]({{< relref "vendure-plugin-metadata" >}}#entities) and otherwise define any other providers and controllers just like any [Nestjs module](https://docs.nestjs.com/modules).