Automated summary
Implements health check endpoints for service liveness, readiness, dependency monitoring, and graceful shutdown.
Strengths
- Separates liveness, readiness, and startup probes and specifies the expected status codes.
- Includes a typed TypeScript HealthChecker with registerable dependency checks.
- Handles graceful shutdown by flipping readiness to 503 while connections drain.
- Shows a Kubernetes probe configuration snippet.
Limitations
- The code sample is TypeScript/Node.js-oriented and does not show route wiring for a specific HTTP framework.
- Does not cover probe threshold tuning such as timeouts, periods, and failure thresholds.
- Assumes an orchestrator or load balancer context; less relevant for services without dependencies or traffic-draining needs.
Use this when a service needs probe endpoints for Kubernetes, a load balancer, or another orchestrator to manage traffic and termination.
Avoid it for static sites or serverless functions that have no critical dependencies and do not need readiness or shutdown signaling.
Security analysis
SafeThis skill is a documentation/reference guide for implementing health check endpoints. It contains no executable commands, no destructive actions, no network exfiltration, and no use of tools. The code examples are TypeScript and YAML configuration snippets for service health monitoring, which pose no meaningful execution risk.
No concerns found
How this analysis is madeExamples
Add /health/live, /health/ready, and /health/startup endpoints to my Node.js service, including database and Redis readiness checks and 503 responses during graceful shutdown.Review my existing health check implementation and separate liveness from readiness so Kubernetes does not restart the pod when a dependency is temporarily down.Update my service so SIGTERM marks the instance as not ready, waits for in-flight requests, and returns component-level health details.Health Checks
Implement health check endpoints for service readiness, liveness, and dependency monitoring
When to Use
- Deploying to Kubernetes or any orchestrator that uses health probes
- Load balancers need to know if an instance can handle traffic
- Monitoring dashboards need service status at a glance
- Graceful shutdown requires draining connections before terminating
Instructions
- Implement three endpoints:
/health/live(liveness),/health/ready(readiness),/health/startup(startup). - Liveness — Is the process alive and not deadlocked? Should be lightweight (no dependency checks). Returns 200 if the process can respond.
- Readiness — Can this instance handle traffic? Checks database connections, cache availability, and critical dependencies. Returns 200 when ready, 503 when not.
- Startup — Has the service finished initializing? Used for slow-starting services to prevent premature liveness failures.
- Set the readiness check to return 503 during graceful shutdown to stop receiving new traffic.
- Health check responses should include component-level detail for debugging.
// health/health-controller.ts
interface HealthComponent {
name: string;
status: 'up' | 'down' | 'degraded';
latency?: number;
details?: string;
}
interface HealthResponse {
status: 'healthy' | 'unhealthy' | 'degraded';
uptime: number;
timestamp: string;
components: HealthComponent[];
}
export class HealthChecker {
private ready = false;
private shuttingDown = false;
private startTime = Date.now();
private checks: Array<{ name: string; check: () => Promise<HealthComponent> }> = [];
registerCheck(name: string, check: () => Promise<HealthComponent>) {
this.checks.push({ name, check });
}
setReady(ready: boolean) {
this.ready = ready;
}
setShuttingDown() {
this.shuttingDown = true;
this.ready = false;
}
async liveness(): Promise<{ status: number; body: object }> {
return {
status: 200,
body: { status: 'alive', uptime: Date.now() - this.startTime },
};
}
async readiness(): Promise<{ status: number; body: HealthResponse }> {
if (this.shuttingDown || !this.ready) {
return {
status: 503,
body: {
status: 'unhealthy',
uptime: Date.now() - this.startTime,
timestamp: new Date().toISOString(),
components: [
{
name: 'server',
status: 'down',
details: this.shuttingDown ? 'shutting down' : 'not ready',
},
],
},
};
}
const components = await Promise.all(
this.checks.map(async ({ name, check }) => {
try {
return await check();
} catch (err) {
return { name, status: 'down' as const, details: String(err) };
}
})
);
const allUp = components.every((c) => c.status === 'up');
const anyDown = components.some((c) => c.status === 'down');
return {
status: anyDown ? 503 : 200,
body: {
status: anyDown ? 'unhealthy' : allUp ? 'healthy' : 'degraded',
uptime: Date.now() - this.startTime,
timestamp: new Date().toISOString(),
components,
},
};
}
}
// Registering checks
const health = new HealthChecker();
health.registerCheck('database', async () => {
const start = Date.now();
await pool.query('SELECT 1');
return { name: 'database', status: 'up', latency: Date.now() - start };
});
health.registerCheck('redis', async () => {
const start = Date.now();
await redis.ping();
return { name: 'redis', status: 'up', latency: Date.now() - start };
});
// Graceful shutdown
process.on('SIGTERM', () => {
health.setShuttingDown();
// Allow in-flight requests to complete
setTimeout(() => process.exit(0), 30000);
});
Details
Kubernetes probe configuration:
livenessProbe:
httpGet: { path: /health/live, port: 3000 }
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 3 # Restart after 3 failures
readinessProbe:
httpGet: { path: /health/ready, port: 3000 }
periodSeconds: 5
failureThreshold: 2 # Remove from service after 2 failures
startupProbe:
httpGet: { path: /health/startup, port: 3000 }
periodSeconds: 5
failureThreshold: 30 # Allow up to 150s for startup
Liveness vs readiness: Liveness failure triggers a pod restart. Readiness failure removes the pod from the service endpoint (no traffic routed to it). Making liveness too strict causes unnecessary restarts. Making readiness too lenient routes traffic to broken instances.
Health check anti-patterns:
- Checking dependencies in the liveness probe (a database outage restarts all pods)
- Not setting timeouts on dependency checks (health check hangs)
- Returning 200 during shutdown (new requests arrive after drain starts)
- Exposing sensitive information in health responses (connection strings, credentials)
Source
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Process
- Read the instructions and examples in this document.
- Apply the patterns to your implementation, adapting to your specific context.
- Verify your implementation against the details and edge cases listed above.
Harness Integration
- Type: knowledge — this skill is a reference document, not a procedural workflow.
- No tools or state — consumed as context by other skills and agents.
Success Criteria
- The patterns described in this document are applied correctly in the implementation.
- Edge cases and anti-patterns listed in this document are avoided.
From the file to a first result
The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.
View the source and supporting filesThis download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.
1. Download the file
Download SKILL.mdFrom the root of a test project, save the file as .skill-downloads/health-checks-mrx3xz91/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.
Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.
mkdir -p '.skill-downloads/health-checks-mrx3xz91' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/health-checks-mrx3xz91/download' --output '.skill-downloads/health-checks-mrx3xz91/SKILL.md.part' && mv '.skill-downloads/health-checks-mrx3xz91/SKILL.md.part' '.skill-downloads/health-checks-mrx3xz91/SKILL.md'2. Check prerequisites
Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.
No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.
The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.
3. Load the skill
This file does not provide a usable name/description header for this native procedure. It remains available to download and inspect; use the manual method below.
Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.
4. Try a first task
Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:
Read .skill-downloads/health-checks-mrx3xz91/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.
Configure a Chat Channel with SecretRefs
DevOps
Set up chat channels using non-interactive commands, with secrets only as SecretRefs. Covers gather, mutate, repair, and prove steps for reliable delivery.
Investigate ClickHouse CI Failures
DevOps
Investigate a ClickHouse CI failure end-to-end from a PR or S3 report URL. Fetches failed tests, classifies flaky vs real regression, and checks for existing issues/fixes.
Ansible PR Review
DevOps
Reviews an Ansible PR following the project's standardized process, including changelog checks, test coverage validation, and feedback tracking.