You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rove clarity on usage and configuration. Renamed section titles and expanded content to cover both liveness and readiness health checks for the Tyk Gateway.
Contributor checklist
Reviewed PR Code suggestions and updated accordingly
Tyklings: Labled the PR with the relevant releases
…rove clarity on usage and configuration. Renamed section titles and expanded content to cover both liveness and readiness health checks for the Tyk Gateway.
Stating that /hello always returns HTTP 200 OK may need nuance if the endpoint itself is unreachable or disabled via config; also verify that MDCB/RPC presence in /hello details is consistent across versions.
### How it responds-**Always returns `HTTP 200 OK`** (even when components are failing).
-**Check the response body** to see which components are healthy or failing
### When to use `/hello`-**Load balancers** - Route traffic to instances that respond
-**Basic monitoring** - Simple uptime checks
-**MDCB setups** - Monitor both Management and Worker Gateways
### Configuration
The endpoint runs on `/hello` by default. To change it:
```yamlhealth_check_endpoint_name: "status"
Updates every 10 seconds - Health status is cached and refreshed automatically
Always responds with 200 - Even when Redis or Dashboard are down (check response body for details)
Use for load balancers - Perfect for HAProxy, NGINX, AWS ALB health checks
</details>
<details><summary><a href='https://github.com/TykTechnologies/tyk-docs/pull/6871/files#diff-1f2dc0abe0799b41bbf67dc8ed7db54ea185dda0ed315dff044d7b6f3abcaef7R114-R144'><strong>Config Reference</strong></a>
Confirm the config keys `readiness_check_endpoint_name` and `health_check_endpoint_name` and linked anchors exactly match the current configuration docs and OSS/Pro scopes.
</summary>
```markdown
### Configuration
The endpoint runs on `/ready` by default. To change it:
```yaml
readiness_check_endpoint_name: "status-ready"
Use this endpoint for basic health monitoring and load balancer health checks. This check returns 200 when the Gateway has started and is attempting to or has arrived to a stable condition.
How it responds
Always returns HTTP 200 OK (even when components are failing).
Check the response body to see which components are healthy or failing
When to use /hello
Load balancers - Route traffic to instances that respond
Basic monitoring - Simple uptime checks
MDCB setups - Monitor both Management and Worker Gateways
Configuration
The endpoint runs on /hello by default. To change it:
</details>
<details><summary><a href='https://github.com/TykTechnologies/tyk-docs/pull/6871/files#diff-1f2dc0abe0799b41bbf67dc8ed7db54ea185dda0ed315dff044d7b6f3abcaef7R36-R49'><strong>K8s Probes</strong></a>
Kubernetes probe examples may need timeouts, initial delays, and failureThresholds for production; consider adding recommended values or a note.
</summary>
```markdown
### Kubernetes Deployments
```yaml
# Liveness probe - restarts pod if Gateway process is dead
livenessProbe:
httpGet:
path: /hello
port: 8080
# Readiness probe - removes from service when not ready
readinessProbe:
httpGet:
path: /ready
port: 8080
Provide sane probe timing defaults to avoid flapping during startup or transient dependency issues. Include initialDelaySeconds, periodSeconds, and failureThreshold to reduce false negatives.
### Kubernetes Deployments
```yaml
# Liveness probe - restarts pod if Gateway process is dead
livenessProbe:
httpGet:
path: /hello
port: 8080
+ initialDelaySeconds: 10+ periodSeconds: 10+ failureThreshold: 3
# Readiness probe - removes from service when not ready
readinessProbe:
httpGet:
path: /ready
port: 8080
+ initialDelaySeconds: 5+ periodSeconds: 5+ failureThreshold: 3
<details><summary>Suggestion importance[1-10]: 7</summary>
__
Why: Adding sane probe timing defaults reduces flapping and false negatives, improving deployability. It’s a practical enhancement consistent with the PR’s Kubernetes guidance, though not critical to correctness.
</details></details></td><td align=center>Medium
</td></tr><tr><td>
<details><summary>Clarify readiness 503 conditions</summary>
___
**Clarify that <code>/ready</code> may temporarily return 503 during startup, config reloads, or <br>graceful shutdown, to prevent misconfiguration of probes with too-aggressive failure <br>thresholds. Add guidance to set appropriate initialDelay and failureThreshold in <br>Kubernetes examples.**
[tyk-docs/content/planning-for-production/ensure-high-availability/health-check.md [18-19]](https://github.com/TykTechnologies/tyk-docs/pull/6871/files#diff-1f2dc0abe0799b41bbf67dc8ed7db54ea185dda0ed315dff044d7b6f3abcaef7R18-R19)
```diff
| `/hello` | **Liveness check** | Load balancers, basic monitoring | Always 200 OK |
-| `/ready` | **Readiness check** | Kubernetes, traffic routing decisions | 200 OK when ready, 503 when not |
+| `/ready` | **Readiness check** | Kubernetes, traffic routing decisions | 200 OK when ready, 503 during startup/reload/shutdown |
Suggestion importance[1-10]: 6
__
Why: The clarification is accurate and prevents misconfiguration by explaining normal 503 conditions for /ready. It’s a helpful doc improvement but moderate in impact as it refines wording in a reference table.
Low
Add endpoint reachability checks
Include a non-destructive HTTP check to verify the /hello and /ready endpoints themselves, helping distinguish endpoint exposure issues (ports/ingress) from backend dependency failures.
**Redis connection failed**:
- Check Redis is running: `redis-cli ping`
- Verify connection settings in Gateway config
- Check network connectivity to Redis
+- Verify probes can reach endpoints: `curl -sS http://<pod-ip>:8080/hello` and `curl -i http://<pod-ip>:8080/ready`
Suggestion importance[1-10]: 5
__
Why: The added troubleshooting step is useful and accurate, helping distinguish ingress/port issues from backend failures. It’s a minor but relevant documentation enhancement.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
User description
…rove clarity on usage and configuration. Renamed section titles and expanded content to cover both liveness and readiness health checks for the Tyk Gateway.
Contributor checklist
New Contributors
masterPR Type
Documentation
Description
Add readiness
/readyendpoint documentationClarify liveness
/hellobehavior and useProvide Kubernetes probe configurations
Add config keys and troubleshooting guidance
Diagram Walkthrough
File Walkthrough
health-check.md
Document readiness and liveness endpoints with probestyk-docs/content/planning-for-production/ensure-high-availability/health-check.md
/readyreadiness endpoint with behavior and config/helloliveness endpoint usage and examples