docs: rename the gateway's keep alive values to health check

src/pages/docs/argo-cd/instances/helm-chart-values.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2026-08-27
-modDate: 2026-08-27
+modDate: 2026-09-07
 title: Argo CD Gateway Chart Values
 description: Gateway Helm chart values and their descriptions
 navOrder: 10
@@ -32,8 +32,8 @@ hideInThisSectionHeader: true
 | gateway.octopus.serverThumbprint | `""` | The thumbprint of the Octopus Deploy server the gateway is communicating with. This should only be used if you wish to pin the certificate. |
 | gateway.octopus.plaintext | `false` | Disables TLS on the connection to the Octopus Deploy server This should only be used if your Octopus Server is running without a certificate on its gRPC listener. |
 | gateway.octopus.serverCertificate | `""` | DEPRECATED: use gateway.serverCertificates instead - The base64-encoded public key of the self-signed x509 certificate or root CA certificate used by the target Octopus Server. Must be in the PEM format. |
-| gateway.octopus.keepAlive.intervalSeconds | `30` | Duration between sending a keep alive to the Octopus Deploy server. Set to 0 to disable keep alives. |
-| gateway.octopus.keepAlive.maxConsecutiveFailures | `10` | Maximum number of keep alive consecutive failures before the application will restart |
+| gateway.octopus.healthCheck.interval | `"30s"` | Duration between health checks sent to the Octopus Deploy server, for example 30s or 1m. Set to 0 to disable health checks, which should only be for troubleshooting (error-recovery is limited when health checks are disabled). |
+| gateway.octopus.healthCheck.giveUpAfter | `"5m"` | Exit once the Octopus Deploy server has gone unanswered for this long, so the pod is restarted, for example 5m or 1h. |
 | gateway.argocd.serverGrpcUrl | `""` | The gRPC url (including the port) of the Argo CD instance to communicate with |
 | gateway.argocd.authenticationToken | `""` | The bearer token used to authenticate with the Argo CD instance. If supplied, a Kubernetes secret is created to hold this token. Mutually exclusive with authenticationTokenSecretName/authenticationTokenSecretKey, and with projectAuthentication/projectAuthenticationSecretName. |
 | gateway.argocd.authenticationTokenSecretName | `""` | Required when authenticationToken is not set: name of an existing secret that contains the Argo CD authentication token. When authenticationToken is set, this overrides the default secret name. Mutually exclusive with projectAuthentication/projectAuthenticationSecretName. |

src/pages/docs/argo-cd/instances/index.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2025-09-15
-modDate: 2026-06-11
+modDate: 2026-09-07
 navSection: Argo CD Instances
 navTitle: Overview
 title: Overview
@@ -44,7 +44,7 @@ If your Octopus Server sits behind a load balancer, proxy, or firewall, make sur
 :::
 
 :::div{.hint}
-The gateway holds long-lived gRPC streams and sends a keep-alive every 30 seconds by default. If a load balancer between the cluster and Octopus Server closes idle connections, set its idle timeout to comfortably exceed the keep-alive interval (`gateway.octopus.keepAlive.intervalSeconds`).
+The gateway holds long-lived gRPC streams and sends a health check to Octopus Server every 30 seconds by default. If a load balancer between the cluster and Octopus Server closes idle connections, set its idle timeout to comfortably exceed the health check interval (`gateway.octopus.healthCheck.interval`).
 :::
 
 ## Installing the Octopus Argo CD Gateway

src/pages/docs/argo-cd/troubleshooting.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2025-09-15
-modDate: 2026-06-11
+modDate: 2026-09-07
 title: Troubleshooting Argo CD in Octopus
 navTitle: Troubleshooting
 description: How to resolve configuration issues
@@ -174,24 +174,24 @@ Behavior:
 - Deployments with Argo CD steps fail intermittently with gRPC connection errors, and succeed when retried
 - The "Gateway connectivity" tab of the Argo CD instance intermittently shows "Unavailable", depending on when the last health check ran
 - The gateway pod logs show stream errors followed by an immediate reconnection
-- If the load balancer drops connections silently instead of closing them, the logs show failing keep alives (`keep alive check failed - cancelling subscribers` with `DeadlineExceeded` errors) and the gateway pod restart count climbs at a regular cadence
+- If the load balancer drops connections silently instead of closing them, the logs show failing health checks (`keep alive check failed - cancelling subscribers` with `DeadlineExceeded` errors) and the gateway pod restart count climbs at a regular cadence
 
 Cause:
 
 - A load balancer or proxy between the gateway and Octopus Server closes connections it considers idle
-- The gateway sends a keep alive to Octopus Server every 30 seconds by default to hold the connection open. If the load balancer's idle timeout is shorter than the keep alive interval (or keep alives are disabled), the connection is terminated before the next keep alive is sent
+- The gateway sends a health check to Octopus Server every 30 seconds by default to hold the connection open. If the load balancer's idle timeout is shorter than the health check interval (or health checks are disabled), the connection is terminated before the next health check is sent
 
 Resolution:
 
-- Increase the idle timeout on your load balancer so it comfortably exceeds the keep alive interval (`gateway.octopus.keepAlive.intervalSeconds`, default 30 seconds)
-- Alternatively, reduce the keep alive interval below the load balancer's idle timeout:
+- Increase the idle timeout on your load balancer so it comfortably exceeds the health check interval (`gateway.octopus.healthCheck.interval`, default 30 seconds)
+- Alternatively, reduce the health check interval below the load balancer's idle timeout:
 
 ```bash
 helm upgrade --atomic \
 --version "1.0.0" \
 --namespace "{{GATEWAY_NAMESPACE}}" \
 --reset-then-reuse-values \
---set gateway.octopus.keepAlive.intervalSeconds="15" \
+--set gateway.octopus.healthCheck.interval="15s" \
 {{EXISTING_HELM_RELEASE_NAME}} \
 oci://registry-1.docker.io/octopusdeploy/octopus-argocd-gateway-chart
 ```
@@ -299,7 +299,9 @@ Behavior:
 Cause:
 
 - Live Status is not enabled
+- Project doesn't have any deployments
 
 Resolution:
 
-- Enable Live Status via the "Live Status" toggle switch at the top of the dashboard.
+- Enable Live Status via the "Live Status" toggle switch at the top of the dashboard
+- Deploy a release in the desired project

src/pages/docs/kubernetes/live-object-status/troubleshooting/index.md

@@ -62,6 +62,35 @@ The cleanest way to do this is to delete and re-install your Kubernetes agent en
 If deleting your Kubernetes agent is not an option for your use case, you can also delete the Kubernetes monitor's authentication secret and restart the Kubernetes monitor pod to trigger re-registration.
 The authentication secret lives in the same namespace that your Kubernetes agent was installed in and has a name similar to `<agent name>-kubernetesmonitor-authentication`.
 
+### Kubernetes Monitor connection drops at regular intervals (load balancer idle timeout) \{#kubernetes-monitor-load-balancer-timeout}
+
+Behavior:
+
+- The Kubernetes monitor installs and connects successfully, but loses its connection to Octopus Server after every quiet period of the same length (e.g. 60 seconds without activity)
+- The "connectivity" tab of the Kubernetes agent intermittently shows "Offline" for the Kubernetes monitor component, depending on when the last health check ran
+- The Kubernetes monitor pod logs show stream errors followed by an immediate reconnection
+- If the load balancer drops connections silently instead of closing them, the logs show failing health checks (`keep alive check failed - cancelling subscribers` with `DeadlineExceeded` errors) and the Kubernetes monitor pod restart count climbs at a regular cadence
+
+Cause:
+
+- A load balancer or proxy between the gateway and Octopus Server closes connections it considers idle
+- The Kubernetes monitor sends a health check to Octopus Server every 30 seconds by default to hold the connection open. If the load balancer's idle timeout is shorter than the health check interval (or health checks are disabled), the connection is terminated before the next health check is sent
+
+Resolution:
+
+- Increase the idle timeout on your load balancer so it comfortably exceeds the health check interval (`gateway.octopus.healthCheck.interval`, default 30 seconds)
+- Alternatively, reduce the health check interval below the load balancer's idle timeout:
+
+```bash
+helm upgrade --atomic \
+  --version "2.*.*" \
+  --namespace ""octopus-agent-$AGENT_NAME"" \
+  --reuse-values \
+  --set monitor.healthCheck.interval ="15s" \
+    $HELM_RELEASE \
+    oci://registry-1.docker.io/octopusdeploy/kubernetes-agent
+```
+
 ## Unexpected object statuses
 
 ### Out of date or slow to update object statuses

src/pages/docs/packaging-applications/build-servers/buildkite.md

@@ -155,5 +155,5 @@ There is no Buildkite plugin for pushing [build information](/docs/packaging-app
 
 - [Octopus CLI](/docs/octopus-rest-api/cli)
 - [Using OpenID Connect with the Octopus API](/docs/octopus-rest-api/openid-connect)
-- [Using OpenID Connect with other issuers](/docs/octopus-rest-api/openid-connect/other-issuers)
+- [Using OpenID Connect with other issuers](/docs/api/authentication/openid-connect/other-issuers)
 - [Create Release Buildkite plugin](https://github.com/OctopusDeploy/create-release-buildkite-plugin)