Menú
>-
De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.
Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.
npx skills add https://github.com/CleanExpo/NodeJS-Starter-V1 --skill health-checkEl comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.
¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.
Route complex requests to the right specialist agent or chain of agents. This skill acts as the central brain of an agent swarm — it analyses what the user needs, determines which specialist domain(s) are required, and coordinates parallel or sequential agent execution. Use this skill when a request spans multiple domains (e.g., "research competitors and create a pitch deck"), when you need to decide which specialist should handle an ambiguous request, or when a task requires a multi-step pipeline across different skills. Triggers on: multi-step requests, cross-domain tasks, "coordinate", "plan this out", "I need help with multiple things", or any complex request that touches more than one specialist area. Also triggers when the user seems unsure which tool or approach to use.
>-
Hybrid DAG execution primitive combining deterministic and agentic nodes with hard iteration caps
Mostrando SKILL.md
Basado en la clasificación ocupacional SOC
| id | health-check |
| name | health-check |
| type | skill |
| version | 1.0.0 |
| created | 20/03/2026 |
| modified | 20/03/2026 |
| status | active |
| metadata | {"author":"NodeJS-Starter-V1","version":"1.0.0","locale":"en-AU"} |
| description | >- |
| context | fork |
Codifies the project's three-tier health probe architecture (shallow liveness, readiness, deep dependency checks), Docker container healthchecks, cron-based periodic monitoring, route discovery verification, and the comprehensive system health script. Patterns align with Kubernetes probe conventions even when running outside K8s.
Codifies liveness, readiness, and deep dependency health endpoints for NodeJS-Starter-V1's Next.js and FastAPI services, covering three-tier probe architecture, Docker healthchecks, cron-based monitoring, route discovery verification, and the system health script.
metrics-collector instead)structured-logging instead)dashboard-patterns instead)graceful-shutdown when available)Promise.all or asyncio.gather. Never check sequentially — a slow database should not delay the Redis check.| Endpoint | Type | Location |
|---|---|---|
GET /health | Liveness |
apps/backend/src/api/routes/health.pyGET /ready | Readiness | apps/backend/src/api/routes/health.py |
GET /api/agents/{id}/health | Agent health | apps/backend/src/api/routes/agent_dashboard.py |
| Endpoint | Type | Location |
|---|---|---|
GET /api/health | Shallow liveness | apps/web/app/api/health/route.ts |
GET /api/health/deep | Deep dependency | apps/web/app/api/health/deep/route.ts |
GET /api/health/routes | Route discovery | apps/web/app/api/health/routes/route.ts |
GET /api/cron/health-check | Periodic cron | apps/web/app/api/cron/health-check/route.ts |
| Service | Command | Interval | Timeout | Retries |
|---|---|---|---|---|
| PostgreSQL | pg_isready -U starter_user -d starter_db | 10s | 5s | 5 |
| Redis | redis-cli ping | 10s | 5s | 5 |
scripts/health-check.ps1 — 6-phase comprehensive health check (prerequisites, database, backend, frontend, integration, summary) with exit code 0 (healthy) or 1 (unhealthy).
All health endpoints use a three-state status:
| Status | HTTP Code | Meaning | Action |
|---|---|---|---|
healthy | 200 | All systems operational | None |
degraded | 200 | Functional but impaired | Monitor, alert |
unhealthy | 503 | Cannot serve requests | Remove from load balancer |
if any dependency is unhealthy → overall = unhealthy (503)
else if any dependency is degraded → overall = degraded (200)
else → overall = healthy (200)
Returns immediately with minimal computation. Used by load balancers and orchestrators to confirm the process is alive.
Backend (/health):
@router.get("/health")
async def health_check() -> dict[str, str]:
return {
"status": "healthy",
"timestamp": datetime.now().isoformat(),
"version": "0.1.0",
}
Frontend (/api/health):
interface HealthResponse {
status: "healthy" | "degraded" | "unhealthy";
timestamp: string;
version: string;
uptime: number;
environment: string;
}
Rules: No database calls, no external service checks, no computation. Must respond in < 50ms.
Confirms the service can accept and process requests. Checks that critical dependencies are reachable.
Backend (/ready):
@router.get("/ready")
async def readiness_check() -> dict[str, str]:
# Check database connectivity
# Check Redis connectivity
# Check AI provider availability
return {"status": "ready", "timestamp": datetime.now().isoformat()}
Rules: Check only fast, critical dependencies (database, cache). Timeout each check at 2–5 seconds. Do not check optional or slow services.
Checks all dependencies in parallel with latency measurement. Used for debugging and monitoring dashboards, not for load balancer probes (too slow).
Frontend (/api/health/deep):
interface DependencyCheck {
name: string;
status: "healthy" | "degraded" | "unhealthy" | "unchecked";
latency_ms: number | null;
error: string | null;
last_checked: string;
}
Each dependency checker follows this pattern:
AbortSignal.timeout(5000))Date.now() - start)healthy (success), degraded (slow or partial), unhealthy (error/timeout)Checks run in parallel via Promise.all:
const [database, backend, verification] = await Promise.all([
checkDatabase(),
checkBackend(),
checkVerificationSystem(),
]);
The summary aggregates results:
const summary = {
total_checks: checks.length,
passed: checks.filter(c => c.status === "healthy").length,
failed: checks.filter(c => c.status === "unhealthy").length,
degraded: checks.filter(c => c.status === "degraded").length,
};
Docker Compose healthchecks use CMD-SHELL with service-native commands:
services:
postgres:
healthcheck:
test: ["CMD-SHELL", "pg_isready -U starter_user -d starter_db"]
interval: 10s
timeout: 5s
retries: 5
redis:
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 5
For application containers, use curl or wget against the liveness endpoint:
backend:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
start_period gives the application time to initialise before healthchecks begin. Use depends_on with condition: service_healthy to sequence container startup.
The project's /api/cron/health-check runs every 5 minutes, pings the backend, and logs results. Secured with CRON_SECRET bearer token.
Pattern for adding new periodic checks:
export async function GET(request: Request) {
// 1. Verify CRON_SECRET
const authHeader = request.headers.get("authorization");
if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
return new NextResponse("Unauthorized", { status: 401 });
}
// 2. Run checks with latency measurement
const start = Date.now();
const response = await fetch(`${backendUrl}/health`, {
signal: AbortSignal.timeout(5000),
});
const latency = Date.now() - start;
// 3. Log results
logger.info("Health check cron", { backend: response.ok, latency });
// 4. Alert if unhealthy
if (!response.ok) { logger.error("Backend unhealthy"); }
// 5. Return results
return NextResponse.json({ status: response.ok ? "healthy" : "unhealthy" });
}
The /api/health/routes endpoint discovers all API routes by scanning the filesystem and optionally verifies each GET endpoint:
app/api/ for route.ts files?verify=true): Send GET request to each endpoint with 5-second timeoutverified (200 OK), error (non-200 or timeout), unverified (not tested)When integrating a new service, add a checker following this template:
async function checkNewService(): Promise<DependencyCheck> {
const start = Date.now();
const result: DependencyCheck = {
name: "service_name",
status: "unchecked",
latency_ms: null,
error: null,
last_checked: new Date().toISOString(),
};
try {
// Service-specific check (e.g., ping, SELECT 1, PING)
const response = await fetch(serviceUrl, {
signal: AbortSignal.timeout(5000),
});
result.latency_ms = Date.now() - start;
result.status = response.ok ? "healthy" : "degraded";
if (!response.ok) result.error = `HTTP ${response.status}`;
} catch (e) {
result.latency_ms = Date.now() - start;
result.status = "unhealthy";
result.error = e instanceof Error ? e.message : "Unknown error";
}
return result;
}
Then add it to the Promise.all array in the deep health endpoint.
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| Database query in liveness probe | Probe fails when DB is slow, kills healthy process | Liveness = process alive only; DB check in readiness |
| Sequential dependency checks | Total latency = sum of all checks | Promise.all / asyncio.gather for parallel |
| 200 OK when unhealthy | Load balancer keeps routing traffic to broken instance | 503 for unhealthy, 200 for healthy/degraded |
| No timeout on dependency checks | Single hung dependency blocks entire health response | AbortSignal.timeout(5000) on every check |
| Exposing sensitive details in health response | Internal errors, stack traces leaked to public | Return status + latency only; log details server-side |
No start_period in Docker healthcheck | Container marked unhealthy during boot | Set start_period to cover startup time |
| Hardcoded service URLs in health checks | Breaks across environments | Use environment variables (BACKEND_URL, etc.) |
healthy / degraded / unhealthy status valuestimestamp and versionPromise.all or asyncio.gatherinterval, timeout, retries configuredstart_period covers application boot timecondition: service_healthy for dependent servicesmetrics-collectorstructured-logging[AGENT_ACTIVATED]: Health Check
[PHASE]: {Design | Implementation | Review}
[STATUS]: {in_progress | complete}
{health check analysis or implementation guidance}
[NEXT_ACTION]: {what to do next}
health_check_duration_ms histogram per dependencyhealth_check_status gauge (1=healthy, 0.5=degraded, 0=unhealthy)SYS_HEALTH_DEPENDENCY_UNAVAILABLE (503) — critical dependency unreachableSYS_HEALTH_TIMEOUT (504) — dependency check exceeded timeout/api/cron/health-check runs every 5 minutes with CRON_SECRET authStatusPulse component for live dependency status indicatorsDataStrip for health check latency metrics